[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Glibc regex concurrency issues (Was: (ITS#3932) regex/librewrite concurrency issue

>> I'll give it a spin.  In this case, I need to backout the fix to
>> ITS#3932
>> that unfortunately made it into 2.2.28 and 2.3.5.  No problem, I've
>> plenty
> 1. Is it considered harmful to tweak rewrite-int.h and #undef
> USE_REWRITE_LDAP_PVT_THREADS on a 2.3.5 tree? (I run Solaris,
> -D_REENTRANT, and for right or wrong, believe Sun's claim to have MT-Safe
> regex under those conditions.) Is that a comprehensive
> compile-time 'backout' to ITS#3932 fix?

No, USE_REWRITE_LDAP_PVT_THREADS has nothing to do with this issue; that's
required to use librewrite in slapd because it takes care of high-level
concurrency, while it assumes regexes are thread-safe.  If you want to
back out the quick fix I applied to 2.3.5 (and which will be removed, I
guess, in 2.3.6, coming soon), you rather need to apply

rewrite-int.h 1.17 -> 1.18
rule.c 1.18 -> 1.19

> 2. I think a vendor-supplied library is likely to perform better on their
> given architecture than some of the off-the-shelf implementations.
> (Hopefully, that's part of what we pay them for?) So if there is an
> inclusion of, say, Henry Spencer regex, I'd like that to be conditional.
> I'll leave that purposefully vague--my favorite way would be a "known bad"
> list, but unless that's upstream autoconf code, that could be a nightmare.

I guess Howard meant that anyone who doesn't trust its system's regex
should take care of using another implementation.  What I did this morning

- look that Spencer stuff up with google
- untar it
- configure
- make
- make install
- CPPFLAGS=-I/path/to/include/rxspencer LDFLAGS=-L/path/to/lib/
- configure
- make depend && make

No hidden libraries buried in the source or so.  I hope when glibc 2.3.5
will appear in the distro I'm using there will be no longer need for any
custom regex...


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497