This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: signals and _REENT
- From: Freddie Chopin <freddie_chopin at op dot pl>
- To: newlib at sourceware dot org
- Date: Sun, 01 Mar 2015 09:17:38 +0100
- Subject: Re: signals and _REENT
- Authentication-results: sourceware.org; auth=none
- References: <54E8FC58 dot 1060503 at op dot pl> <126282749 dot 26790184 dot 1424979571705 dot JavaMail dot zimbra at redhat dot com> <54EF8A3F dot 90104 at op dot pl> <1144371384 dot 26964184 dot 1424986890495 dot JavaMail dot zimbra at redhat dot com> <54EF9634 dot 3010300 at op dot pl> <1189623961 dot 27020411 dot 1424989913735 dot JavaMail dot zimbra at redhat dot com> <EB7C501B-4731-4141-BED2-BF401D895689 at oarcorp dot com> <1428023386 dot 27077645 dot 1424994302865 dot JavaMail dot zimbra at redhat dot com> <523485522 dot 28389601 dot 1425077765152 dot JavaMail dot zimbra at redhat dot com>
On 02/27/2015 11:56 PM, Jeff Johnston wrote:
Modified patch attached.
Does the lock really have to be recursive? It seems that it would be
possible to use non-recursive version. I see _init_signal_r() is the
only place where lock is re-acquired recursively, so this function can
either be made private (static)* - no code in newlib calls it and it's
not prototyped in any header - or it could be converted to a wrapper for
new static function which would _NOT_ use locking, the locks would be
acquired externally and all functions from signal.c would just call this
new "internal" version.
* - in that case locks could be added to _init_signal(), but this
function also doesn't seem to be used, there's also no prototype in any
header...
Regards,
FCh