On Wed, 24 Sep 2003, Rob Siemborski wrote: > think about it. The kernel is responsible for waking processes up when > they are blocking on a lock and it becomes available. If this isn't > happening (causing the need to do locks in a nonblocking fashion) then > something is wrong with the *kernel* not the application.
Agreed, but if we are going to keep the blocking-on-lock behaviour (and I know we are ;-)), we really, really should have a way to timeout and kill the process if that lock does not release after a while. Resilience IS necessary... As an admin, I want to know there are problems from syslog events, not because the whole system stopped. Right now, at least in Linux (which DOES have kernel/glibc bugs in that area) that means we end up needing the slow-as-hell backoff non-blocking locks stuff. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
