[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14404: regexp_exec thread-unsafe
From: |
Paolo Bonzini |
Subject: |
bug#14404: regexp_exec thread-unsafe |
Date: |
Mon, 27 May 2013 00:11:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
Il 20/05/2013 16:20, Ludovic Courtès ha scritto:
> Paul Eggert <address@hidden> skribis:
>
>> On 05/14/2013 02:21 PM, Ludovic Courtès wrote:
>>
>>> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased
>>> on top of pthread_mutex_t?
>>
>> Yes, thanks, that sounds right. I pushed the following patch into gnulib;
>> could you please see whether it fixes the problem for you? It'd be
>> helpful to try it on non-glibc systems too, if possible.
>
> Thank you for the quick reply. I haven’t tested yet, but I have a question:
>
>> --- a/modules/regex
>> +++ b/modules/regex
>> @@ -24,6 +24,7 @@ memmove [test $ac_use_included_regex = yes]
>> mbrtowc [test $ac_use_included_regex = yes]
>> mbsinit [test $ac_use_included_regex = yes]
>> nl_langinfo [test $ac_use_included_regex = yes]
>> +pthread [test $ac_use_included_regex = yes]
>> stdbool [test $ac_use_included_regex = yes]
>> stdint [test $ac_use_included_regex = yes]
>> wchar [test $ac_use_included_regex = yes]
>
> Seems like this is going to add -lpthread to LDFLAGS, right?
>
> That would raise two issues: first, it should add -pthread to both
> CFLAGS and LDFLAGS, not just -lpthread.
>
> Second, Guile can be compiled with and without thread support. In the
> latter case, we wouldn’t want Gnulib to stealthily pull in pthreads.
> How can this be addressed?
Use the lock module instead.
Paolo