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

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Jeff Johnston wrote:

> Can you elaborate of a particular scenario where this causes problems?
> Regarding the version of newlib.  You can check the newlib.h header 
> file which has the version for the snapshot releases.  As you know, 
> I'm just about to cut 1.12.
I was thinking in general terms of the RTEMS reentrancy support which could
vary by newlib version.  So at compile time, we could pick old or new 
version.
RTEMS has been using newlib since about version 1.6 and things haven't 
changed
much but this time it made me think a bit.

> -- Jeff J.
>
> Joel Sherrill wrote:
>
> > Jeff Johnston wrote:
> >
> > > The reentrancy model hasn't changed dramatically.  It is just files 
> > > are managed in the global reentrancy structure now.  See the change 
> > > on 08-22.
> >
> >
> >
> > Is there any way to know which version of newlib one is using at
> > compile time?  It seems as though the reentrancy difference
> > is something we would have to distinguish about in our support
> > code.
> >
> > > -- Jeff J.
> > >
> > > Joel Sherrill wrote:
> > >
> > > > My understanding of the reentrancy code in newlib must have gotten
> > > > totally out of sync with reality.  Is there any documentation
> > > > I can read to catch up and get educated again?
> > > >
> > > > --joel
> > > >
> > > > Jeff Johnston wrote:
> > > >
> > > > > 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.