signals and _REENT

Jeff Johnston jjohnstn@redhat.com
Thu Feb 26 22:35:00 GMT 2015


----- Original Message -----
> From: "Freddie Chopin" <freddie_chopin@op.pl>
> To: newlib@sourceware.org
> Sent: Thursday, February 26, 2015 4:55:00 PM
> Subject: Re: signals and _REENT
> 
> On 02/26/2015 10:41 PM, Jeff Johnston wrote:
> > Actually I did miss something.  Since we are using the global list,
> > we have to thread protect it with locking and unlocking.  The normal way
> > would be
> > to add two new locks: __sigfunc_lock_acquire() and __sigfunc_lock_release()
> > which
> > are needed if not single threaded.  This will cause some breakage for
> > builds that
> > use threads until they define these locks.  Perhaps a single global reent
> > lock might
> > be helpful.
> 
> In that case maybe it would be a good idea to "reuse" the lock that is
> used with _GLOBAL_REENT in stdio? Or do you think separate lock for
> signals and separate lock for stdio would be a better option (smaller
> chance of congestion)?
> 

I had thought of that.  I'm ok with using the _newlib_sfp_lock_start and
_newlib_sfp_lock_end macros as they are defined in stdio/local.h.  If no one
objects, I can do that at least for now.

-- Jeff J.



More information about the Newlib mailing list