bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: regexp_exec thread-unsafe


From: Paolo Bonzini
Subject: Re: 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]