[Date Prev][Date Next]
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
>> that unfortunately made it into 2.2.28 and 2.3.5. No problem, I've
> 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
- make install
- CPPFLAGS=-I/path/to/include/rxspencer LDFLAGS=-L/path/to/lib/
- 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
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497