Proposal to remove std stream and file chain info from reent struct

[Jeff Johnston]

It was in considering your patch that I decided to propose this.  Your 
solution was trying to keep the current code in place and make the 
behaviour optional, but I believe the right answer is to clean this up 
properly.

For example, there are places where the _stdin_r macro is used.  In 
addition, the definition of stdin, stdout, and stderr change if 
_REENT_ONLY is defined.  _REENT_SMALL uses a fake std stream structure 
to minimize initial footprint, but I vaguely remember there being at 
least one scenario (though unlikely) which will not work when playing 
around with std stream assignment.  There are additional cleanup 
routines because of the std streams.  There is the bug that Till 
discovered.  Add on the fact that regular stream I/O has already moved 
to have all open streams on the global reent chain and this sort of 
screams a clean-up is in order.

-- Jeff J.

On 06/17/2010 11:37 AM, Christoph Stoidner wrote:
>
> Hi Jeff,
>
> I had implemented a similar approach and I had discussed it in the post below:
>
> http://sourceware.org/ml/newlib/2010/msg00263.html
>
> My goal was to reduce the number of opened files in case of standard IO access from several threads.
>
> regards
> Christoph
>
> ----- Ursprüngliche Mail -----
> Von: "Till Straumann"<strauman@slac.stanford.edu>
> An: "Jeff Johnston"<jjohnstn@redhat.com>
> CC: "newlib@sources.redhat.com"<newlib@sources.redhat.com>, "Joel Sherrill"<joel.sherrill@oarcorp.com>
> Gesendet: Donnerstag, 17. Juni 2010 17:09:14
> Betreff: Re: Proposal to remove std stream and file chain info from reent struct
>
> Jeff.
>
> I like the idea. However, you would still allocate (from the single
> global chain)
> one set of stdin/stdout/sterr streams per thread, right?
>
> -- Till
>
> On 06/16/2010 03:07 PM, Jeff Johnston wrote:
>> In light of the following post:
>>
>> http://sourceware.org/ml/newlib/2010/msg00376.html
>>
>> I am proposing to remove the std streams from the reentrancy structure
>> and have one global set. As well, the glue chain can also be removed
>> since we would always be using the one chain. I am proposing a new
>> global structure which would house the std streams and the glue chain.
>>
>> The current std stream situation appears to be mostly historical. I'm
>> not sure anyone actually depends on there being std streams per
>> thread. POSIX thread and I/O behaviour certainly wasn't ever
>> considered in the initial implementation.
>>
>> There are obvious benefits to doing this. The reentrancy struct gets
>> smaller. The scenario problem, described in the newlib posted link
>> above, goes away. In addition, the code gets simplified as some
>> reentrant versions of functions are not needed.
>>
>> I am proposing this here first in case any platform has a dependency
>> on the current behaviour or there are some gotchas I haven't thought
>> of.
>>
>> If there are no fundamental objections, I will make the changes and
>> post a patch here for review/comments.
>>
>> -- Jeff J.