Re: LinuxThreads (0.8) are non-preemptive ?

[Albert Siersema <albert@friendly.net>]

> The fact that threads are in separate processes and the
> kernel provides preemptive process scheduling, means that
> LinuxThreads are preemptive.

Sorry, i shouldn't write messages when i'm in Daft Mode (tm)
I meant of course: the Linux kernel _IS_ preemptive and that it
should be quite safe to write a threaded application even
with blocking I/O and such.

The cause of me asking this question is that I read in the FAQ
a while ago:
  http://www.openldap.org/faq/data/cache/228.html:
  OpenLDAP 1.x servers are designed to be used in non-preemptive
  threading environments.
  It is not safe to use OpenLDAP in preemptive threading environments.
  http://www.openldap.org/faq/data/cache/263.html:
  LinuxThreads are preemptive and hence are not safe to use with OpenLDAP 
1.x.

I know that most commercial Unix vendors ship with a threads
implementation that is quite complicated and not preemptive.
An extra and unnecessary burden for both programmer, OS and
threads implementation if you ask me, but okay...
I'd think that leaving the hard work to the kernel would be easier.
(depending on the overhead of the context switch of course)

To cut it short: are there any alternatives to get a threaded OpenLDAP
up & running under Linux. I imagine that performance will be a lot
better (or am i gravely mistaken here :-).
I searched freshmeat for other thread implementations and
i vaguely recall something like uthreads or something.
Any preferred/tested/proven packages ?

To satisfy my own curiousity:
I gather that the preemptive nature of Linux threads can cause
race conditions & dead locks and such when the OpenLDAP thread
implementation expects non-preemptive threads ?
Or are there other issues ?

Albert

PS: I realize this might be a FAQ. Would it be an idea to include
       it in the FAQ files too ?

/\lbert

/---------------------------------------------------------------------\
| Albert Siersema aka loonatic | There are no deadlines any deadlier  |
|                              |  nor limits more limiting than those |
|          albert@friendly.net |  we set (for) ourselves         (la) |
\---------------------------------------------------------------------/