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

RE: OpenLDAP 1.1.2 thread problem



At 06:10 PM 1/11/99 +0100, Per Steinar Iversen wrote:
>===== Original Message from "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org> at 
>11.01.99 17:23
>>At 02:37 PM 1/11/99 +0100, you wrote:
>>>I have installed OpenLDAP 1.1.2 on a production
>>>machine, it works OK for a while (a few hours), then it
>>>becomes confused with a thread problem - see the
>>>attachment to this message, it shows the last
>>>successfull query and then the thread error
>>>messages.
>>
>>Looks like you are running out of resources of some
>>sort.  Likely threads related.  I suspect your system
>>is not automatically reaping detached threads.
>>

Or the threads are not being detached at all.

Check portable.h:
  HAVE_PTHREAD_D4 ?
  HAVE_PTHREAD_FINAL ?
  HAVE_PTHREAD_ATTR_SETDETACH_NP
  HAVE_PTHREAD_ATTR_SETDETACHSTATE ?

I'm testing new code that uses pthread_detach(), if available.

Of course, you could be running out of some other resource.

>I have another version of slapd running on the
>same machine, it is the old UMich 3.3 plus some
>patches from the time before OpenLDAP.
>It uses the same threads and never hangs or crashes -

UMich 3.3 actually only supported a old Draft4 version
of MIT_PTHREADS.  We updated the thread code to support
Pthread final implementations (including newer MIT pthreads
versions).  We haven't done much with the 'draft4' support.
There were patches available to use Final pthreads, but these
were problematic.

I noticed that the Umich and OpenLDAP both rely on creation
of detached threads (which wasn't supported by draft 4) (old
MIT threads, I believe, had an _np() function to set 'detach'
in a thread attribute).

I'm testing a patch to use pthread_detach to detach the thread
after creation.  This might work better on some platforms and
shouldn't have an ill effect on others.

Kurt