This is the mail archive of the
mailing list for the newlib project.
Re: stdio thread safety
- From: Carl Norum <carl at lytro dot com>
- To: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 4 Jun 2013 11:24:58 -0700
- Subject: Re: stdio thread safety
- References: <581E2882-C47A-43B3-9CBB-748F86EEE7F1 at lytro dot com> <20130604082112 dot GA28282 at calimero dot vinschen dot de> <4F60FE24-4413-49D8-8D87-894080CA6178 at lytro dot com> <51AE2BD5 dot 1060204 at op dot pl> <1BDB6943-7636-43C7-A481-2EEBA4ED846F at lytro dot com> <51AE2DBD dot 7050800 at op dot pl>
On Jun 4, 2013, at 11:11 AM, Freddie Chopin <email@example.com> wrote:
> W dniu 2013-06-04 20:05, Carl Norum pisze:
>> Yes, but at least it upstreams the interface. Hopefully that would be useful
>> for people working on this kind of problem in the future. Something like how the
>> calls to __malloc_lock and __malloc_free (or even any of the system calls like _write_r,
>> _isatty_r, etc.) are handled in newlib currently.
> But do note, that empty __malloc_lock() and __malloc_unlock() are provided, so that everything works as expected if you don't need them. In case of stdio it can't be done that easily, because - as you noted - there's this LOCK_INIT() macro for static locks... And your patch just provides another set of names for the ones already used, without providing any implementation...
These will work as expected if __SINGLE_THREAD__ is defined, right? And if they're not,
not implementing them is bad news. Is there a way I can hook up some dummy implmentations
like the syscall ones are? So that they'd be disabled when configuring with
"--disable-newlib-supplied-syscalls", and the linker would tell the library user to come up
with some implementations themselves?
All my patch does is make new interfaces that take pointers, so the init routines can
actually *do* some initialization, which the macro definitions as-is can't.
Maybe I'm missing something here - do you just want me to include some dummy do-nothing
implementations of the lock routines? The only 'empty' __malloc_lock I found in a quick
tree search call these lock routines, so they're not really empty after all.
My only goal here is to be able to build an "out-of-the-box" newlib that will actually
have hooks to do the appropriate locking. As it stands, that's not possible, as far as I
can tell. Corinna's message earlier seemed to indicate to me that I was heading the right
If you have some suggestions for what approach you'd rather I take, I'd be happy to hear