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

Christoph Stoidner
Thu Jun 17 17:35:00 GMT 2010

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" <>
An: "Jeff Johnston" <>
CC: "" <>, "Joel Sherrill" <>
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
> of.
> 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 mailing list