This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]