This is the mail archive of the
newlib@sourceware.org
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:49:41 -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> <C3BCF918-9D79-40F2-B469-72775B026EF8 at lytro dot com> <51AE325A dot 3030401 at op dot pl>
On Jun 4, 2013, at 11:30 AM, Freddie Chopin <freddie_chopin@op.pl> wrote:
> W dniu 2013-06-04 20:24, Carl Norum pisze:
>> Corinna's message earlier seemed to indicate to me that I was heading the right
>> direction here.
>
> Well, you are going in the right direction, I just don't think the patch you sent should be in the tree. But that's just my opinion (;
>
> With some proper assumptions you can live without those locks - I have apps with multiple threads that use stdio and I don't have these locks implemented. So far everything works as expected (;
Yeah - I made some deeper reading of __sinit and __sfp as part of getting this stuff
set up, and it looks like I might not need them after all, as you mention. Each thread
gets its own FILE structure for each of the standard streams, so the work buffers can't
collide anyway. I'm just a little apprehensive about it....
--
Carl Norum
carl@lytro.com