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

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

Jeff:
> Jeff wrote:
> I'm not sure anyone actually depends on there being std streams
> per thread.
     I count on the std streams being in the reentrancy structure in
my custom embedded design.  With no OS, the reentrancy structure is a
good way to get some OS-like features.  Using this trick allows
interrupt handlers to act sort of like processes, for example.
     Till asked about this in his 6/17 email ("I like the idea.
However, you would still allocate (from the single global chain) one
set of stdin/stdout/sterr streams per thread, right?"), but I
haven't seen the answer to that, yet.  If I understand your original
email properly, I think that the answer is no, however.  (If there is
only one global set, then it cannot be per thread--except in a
generate case of only one thread.)
     I do agree with your statement about a cleanup being in order.
     I wouldn't want my use alone to get in the way of a cleanup
that could give better efficiency to everyone, but it could be that
if I'm doing this, then others might be, too--which Till's question
implies.  I am about to go to a new (still custom) platform, so I
could possibly take that opportunity to do it in a different manner,
although I'd naturally prefer not to since it would add some work.
				Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Jeff Johnston
Sent: Wednesday, June 16, 2010 4:07 PM
To: 'newlib@sources.redhat.com'
Cc: Till Straumann; Joel Sherrill
Subject: Proposal to remove std stream and file chain info from reent
struct

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.