This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: signals and _REENT
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jeff Johnston <jjohnstn at redhat dot com>,Freddie Chopin <freddie_chopin at op dot pl>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Thu, 26 Feb 2015 17:35:25 -0500
- Subject: Re: signals and _REENT
- Authentication-results: sourceware.org; auth=none
- References: <54E8FC58 dot 1060503 at op dot pl> <820331943 dot 24407010 dot 1424801251193 dot JavaMail dot zimbra at redhat dot com> <54ECE7F2 dot 60909 at op dot pl> <53234661 dot 25550941 dot 1424885653210 dot JavaMail dot zimbra at redhat dot com> <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>
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?
>-- Jeff J.
--joel