This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] _fwalk walks through thread local FILE pointer


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]