Proposal to remove std stream and file chain info from reent struct
Thu Jun 17 17:35:00 GMT 2010
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
one set of stdin/stdout/sterr streams per thread, right?
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