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

[Antony King <antony dot king at st dot com>]

Hi,

I have a question (in light of my recent experience with the removal of
__ctype_ptr at the cost of binary compatibility) which is...

...will the planned clean up retain binary compatibility with code that
uses the standard I/O streams and has been compiled using the existing
(and older) versions of newlib's stdio.h ?

If the planned changes are compatible then great :-), if not then would
it be feasible to request a compilation option to enable backwards
compatibility ?

Cheers,

Antony.

On 17/06/2010 17:32, Jeff Johnston wrote:
> 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.