Proposal to remove std stream and file chain info from reent struct
Fri Jun 18 13:40:00 GMT 2010
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
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:
> My goal was to reduce the number of opened files in case of standard IO access from several threads.
> ----- UrsprÃ¼ngliche Mail -----
> Von: "Till Straumann"<email@example.com>
> An: "Jeff Johnston"<firstname.lastname@example.org>
> CC: "email@example.com"<firstname.lastname@example.org>, "Joel Sherrill"<email@example.com>
> Gesendet: Donnerstag, 17. Juni 2010 17:09:14
> Betreff: Re: Proposal to remove std stream and file chain info from reent struct
> 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:
>> 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
>> If there are no fundamental objections, I will make the changes and
>> post a patch here for review/comments.
>> -- Jeff J.
More information about the Newlib