Thread pool contexts and SLAPI

[Luke Howard <lukeh@PADL.COM>]

I'm running up against a nasty problem in SLAPI.

The slapi_search_internal() function can be used by plugins
to perform an internal search. It does not take any arguments
that contain any context of the caller.

Inside slapi_search_internal(), fakeConnection() is used to
create internal connection and operation contexts on which to
perform the search.

The problem is that this blows up badly with back-bdb (sending
it spinning) because op->o_threadctx is NULL, and it needs some
thread-specific data in order to get a lock context. 

I'm between a rock and a hard place: I can't change the SLAPI
API to pass any context information (which would easily solve
the problem as the caller will have access to the original
Operation and thus its thread context) Changing the SLAPI API
would break API/ABI compatability with Netscape/Sun ONE, which
is unacceptable.

But I don't know what else to do... I presume that the thread
pools maintain their own TSD for portability, but using 
pthread_getspecific() would presumably have pushed the
problem out of slapd's domain...

And things were going so well too...

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com