Re: Overlays and OpenLDAP multi-threading model

[masarati@aero.polimi.it]

> Hi!
>
>> The overlay stack is called within the execution of an operation.  As
>> such, it only affects the thread that executes that operation, unless
>> your
>> code does something nasty like locking global mutexes.  This implies
>> that
>> it is *not* entirely blocking a connection: a connection can
>> simultaneously spawn multiple operations.  It is not clear from your
>> message how your overlay can affect OpenLDAP connection handling, as
>> this
>> is not usually exposed in overlay handling.
>
> I'm not aware about details of OpenLDAP multi-threading model, so I asked.
> :)
>
> Imagine *if* each thread accepts one connection at time and it does
> it's operations
> in a 'serialized' manner:
> accept connection from client => fills up accordingly structures =>
> pass data to overlay => pass
> data to backend => backend does it's job => pass data back to overlay
> => connection
> response to client. In this case, if overlay processing takes a long
> time, the connection
> from *that* and only *that* client will be delayed.
>
> By your answer I think each thread uses a event loop to perform each
> operation, is that
> right ?


Now I understand a bit more of your question.  OpenLDAP does not work as I
presume you imagined.  There is one thread that listens for requests.  As
soon as a request is received, an operation structure is created, and
queued for execution.  As soon as one thread is available from a thread
pool, the first operation in the queue is executed.  So threads *do not*
accept connections (a connection is a persistent channel between the
client and the server; a connection is not related to a thread).  A
specific thread accepts requests (a request is mapped onto an operation),
and each operation is executed by a different thread.

If your overlay takes a lot of time, in principle it will only affect its
operation.  If the client is performing multiple operations concurrently,
only that operation will be delayed.  Of course, if all operations use
your overlay, and all operations of your overlay take a lot of time, at
some point all the threads of the pool will be busy.  Further requests
will be accepted by the listener thread, but they will be queued until one
thread of the pool is available.

If your overlay (for any reason) takes a long time to process an
operation, but does not intensively use system resources (e.g. because it
is contacting some remote system, and *that* system is taking long to
respond), you may want to increase the size of the thread pool (the
"threads" directive).  In general, this is bad, but it may be good in
special cases like this.

> I'll not touch any thread resources like mutexes, some global variable and
> so on. It will not that evil :)

p.