[PATCH] _fwalk walks through thread local FILE pointer

[Jeff Johnston]

I think that the stdin/stdout/stderr for the thread should also be 
walked in addition to the global list for now.  I don't think that 
should cause problems with Cygwin but if so, we can add an #ifdef check.

-- Jeff J.

Thomas Pfaff wrote:

> Take a look at findfp.c and you will see that all FILE pointers are 
> hold in _GLOBAL_REENT, therefore _fwalk simply does not walk through 
> the real FILE pointer list, but through the thread lokal ones which 
> will contain only stdin, stdout and stderr.
>
> The obsolete REENT ptr can be removed but thats Jeffs decision.
>
> You can search the list why _GLOBAL_REENT was introduced some time 
> ago. The former implementation where every thread has its own pointer 
> list was incorrect, FILE pointers are process global objects.
>
> There is still a problem with stdin, stdout and stderr because every 
> thread has its own buffers for these files. Cygwin has a workaround 
> for this problem, it maps the thread lokal stdin, stdout and stderr to 
> _GLOBAL_REENT aka _impure_ptr FILE pointers. I think that this will a 
> working solution for other platforms as well.
>
> Thomas
>
> Joel Sherrill wrote:
>
>> This isn't right.  You are passed a REENT pointer and cannot
>> simply ignore it.
>>
>> This will break any code that depends upon the existing
>> behavior.  In RTEMS, we use _fwalk as it exists to
>> implement sync() and walk each thread's open files.
>> It is also used as part of the per-thread cleanup
>> dynamically.
>>
>> If you want to have NULL ptr argument imply the global
>> reent, great but don't break it.
>>