[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SLAP_LIGHTWEIGHT_LISTENER, using lazy_sem is a bad design
- To: OpenLDAP Devel <openldap-devel@OpenLDAP.org>
- Subject: SLAP_LIGHTWEIGHT_LISTENER, using lazy_sem is a bad design
- From: Howard Chu <hyc@symas.com>
- Date: Thu, 13 Oct 2005 20:50:05 -0700
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050925 SeaMonkey/1.1a
This solution will deadlock if all worker threads are stuck in a write
wait. Since the semaphore completely blocks the listener thread, there
will be no way to wake up the waiting writers and free up more threads.
Also, blocking the listener thread like this prevents the idletimeout
checker from working. I.e., you have managed to disable two key
mechanisms for returning server resources to the pool, precisely when
they are needed the most.
The listener thread must never block, period.
It would be better to simply have ldap_pvt_thread_pool_submit return a
result code (e.g. LDAP_BUSY if the submitted op will be queued because
there are no available workers, LDAP_SUCCESS otherwise) that is passed
back to the listener thread. When the listener thread gets this result
it should drop all read descriptors from the event set, but keep
monitoring the wake_sds and the write events.
Alternatively we should stop monitoring write events and just let the
writers unblock themselves. Is there a particular reason why we monitor
write events? I don't see any benefit. Eliminating one set of event
sources would reduce our kernel load by half.
Aside from this issue there is definitely a bug in the current
implementation; I see the same event being submitted multiple times in
rapid succession. The CPU usage goes to 100% and there does not appear
to be any end condition that disables the event. This occurs most often
in test033, but should occur in any test that uses syncrepl (or
listener-managed client tasks like syncrepl). After the syncrepl task
has sent a search request to the provider and the first reply arrives,
marking the socket readable. It appears this readable state is not
getting reset.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/