Question for Thomas Pfaff regarding stdio and threads

[Thomas Pfaff]

Christopher Faylor wrote:
> I discovered something today regarding the never-ending saga of getting
> stdio working correctly in threads.
> 
> I found that I needed to initialize the local_clib.__sglue._niobs and
> local_clib.__sglue._iobs fields in the thread's local_clib structure or
> the count of open handles was set incorrectly and _fwalk (which is used
> by setmode) did not operate correctly.  __sinit in
> ~newlib/libc/stdio/findfp.c does this, so we have to mimic it, too.
> 
> The problem is that every thread will have its own copy of _niobs and
> _siobs could, I assume, be reallocated.  That's not good for threads
> which call fopen.
> 
> This seems like a complete mess, and I don't know how to proceed.  It
> seems, once again, like a redesign of newlib is called for, which is
> certainly not something that I want to do.  It is, however, causing the
> 1.5.7 release to stall.  The current behavior causes setmode to be
> inoperable so things which use it, like bzip2 and gzip will operate
> badly on text mode mounts.
> 
> So, my question is:  Do you have any ideas on what to do here?  I'm
> rather stumped.
> 

AFAICS the problem is that fwalk still uses the thread local reent to 
walk through the FILE * list.

I think that this can be avoided by changing

   for (g = &ptr->__sglue; g != NULL; g = g->_next)

in fwalk.c to

   for (g = &_GLOBAL_REENT->__sglue; g != NULL; g = g->_next)

like this is already done in findfp.c, since all FILE pointers are now 
stored in _GLOBAL_REENT aka _impure_ptr.

I did a grep in newlib and the only places where _iobs and _niobs are 
used are findfp and fwalk, therefore i believe that this will fix it.

I can generate a patch for newlib if you agree with this change.

Thomas