--On Sunday, June 22, 2003 12:17 PM -0400 Greg Hudson <ghudson@MIT.EDU> wrote:
> server/mpm/worker/fdqueue.c's second use is also questionable; it
> re-checks its condition once and returns an "interrupted" error code if
> the condition is still false. Depending on how callers handle such an
> error, that could also cause problems.
The problem is that wakeups don't occur correctly.
(server/mpm/worker/fdqueue.c is the relevant one for this topic.)
Specifically, the pthread_cond_wait calls only return after two
pthread_cond_signals. The pattern is this:
- Request comes in.
- Request pushed onto stack by 'main' thread
- This triggers pthread_cond_signal in the main thread
(At this point, all 'workers' are idle and are in pthread_cond_wait.
So, pthread_cond_signal should wake up at least *one* of them...but...)
- ...Nothing happens until...
- Another request comes in.
- Request pushed onto queue by 'main' thread
- Call pthread_cond_signal
- One worker thread *now* is woken up and services the first request
...repeat pattern...
The pthread_cond_signal calls appear to be delayed in this wakeup. A request
can not be serviced until *another* request comes in. This is the core
problem, but we were also able to trivially kernel panic FreeBSD by placing a
load on a threaded MPM. (I personally haven't tried 5.x/-CURRENT in a while,
but we know 4.8 still doesn't work. I have lost access to boxes that can run
-CURRENT.)
We'll note that the worker code works correctly, at least, on Linux, Solaris,
Darwin, and I believe, AIX. So, we don't believe we're doing anything
massively wrong. From a conversation with Alfred (one of the core FreeBSD
kernel guys), libc_r never really was tested with network code (why a rewrite
was thought to be necessary). sendfile() and threads were broken until we
came along and were able to talk with Alfred to get it fixed.
One reason to keep this on dev@svn is that I'm aware that more FreeBSD
developers read this than dev@httpd. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 22 18:38:05 2003