Question for Thomas Pfaff regarding stdio and threads
Tue Jan 27 09:01:00 GMT 2004
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.
More information about the Cygwin-developers