All right, that worked much better.  The database backend interface has been
reverted to what it was before.  The backend for Berkeley DB still needs 
thread-specific
data, but now it maintains that data locally to the module instead of tainting
the server with its own needs. 
  
 Sensibly, when something in the backend needs to store or retrieve something
specific to the thread (a cursor, a lock, or a transaction) it calls a function
that says "please give me a pointer to the thread-specific data region for
this thread; if none exists, create one". 
  
 I'm guessing that when we built the previous arrangement 25 years ago we
were expecting we'd need to store more than just database stuff in that region,
but it turned out not to be the case.  Also we were foolishly envisioning
a Windows port at the time so who knows what was going through our heads.

 

Reply via email to