signals and _REENT

[Jeff Johnston]

Modified patch attached.

-- Jeff J.

----- Original Message -----
From: "Jeff Johnston" <jjohnstn@redhat.com>
To: "Joel Sherrill" <joel.sherrill@OARcorp.com>
Cc: "Newlib Mailing List" <newlib@sourceware.org>
Sent: Thursday, February 26, 2015 6:45:02 PM
Subject: Re: signals and _REENT

----- Original Message -----
> From: "Joel Sherrill" <joel.sherrill@OARcorp.com>
> To: "Jeff Johnston" <jjohnstn@redhat.com>, "Freddie Chopin" <freddie_chopin@op.pl>
> Cc: newlib@sourceware.org
> Sent: Thursday, February 26, 2015 5:35:25 PM
> Subject: Re: signals and _REENT
> 
> 
> 
> On February 26, 2015 5:31:53 PM EST, Jeff Johnston <jjohnstn@redhat.com>
> wrote:
> >----- 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.
> 
> How many locks does newlib require? Is there a per thread factor?
> 

Not sure what you asking.  

After thinking about it, I should have just done
the same thing we do for locking the environ functions and atexit functions so
that no-one has to add anything.  I'll work on it and re-post my patch.

-- Jeff J.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signal.patch
Type: text/x-patch
Size: 3872 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150301/46a022c2/attachment.bin>