This is the mail archive of the
mailing list for the newlib project.
Re: stdio thread safety
- From: Freddie Chopin <freddie_chopin at op dot pl>
- To: newlib at sourceware dot org
- Date: Tue, 04 Jun 2013 20:11:09 +0200
- 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>
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...