httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Apache/pthread and locking problem
Date Wed, 11 Aug 1999 14:54:32 GMT

In article <> you wrote:
> The last days I've played a little bit with the apache-pthread stuff and got
> it running under FreeBSD with the vendor pthread library (uthread) after
> linking in my poll(2) emulation library which is based on select(2). But I got
> it running only in standalone-mode (-X). There the beast works fine.  But in
> standard mode (not -X) I see some sort of locking problem. The connection is
> accepted and then it blocks forever. Interesting is that when I drop the
> connection and once the same child gets another request it seems to unblock
> and process something (at least ktrace shows then the request body).

Ok, I've now traced the problem down. It occurs both in apache-pthread and
even in Apache-mpm with dexter. It's this way:

When a connection is established the worker threads start working. When I push
in the request to the socket immediately I get the response (for instance via
ab or `echo | socket', etc.).  But when I enter the request on the socket
manually, the worker thread usually gets a -1 from read() and does a select()
until data is actually available. Now comes the problem: While the worker
thread is waiting, the thread which does the socket accepts starts over with
his loop and does the accept_mutex_on again. And now the whole process stops
until a new connection comes in. Until then the whole process is suspended
because both flock() and fcntl() based mutexes do suspend the whole process
and not just the current thread. At least that's the case for flock and fcntl
with both FreeBSD uthread and GNU Pth.

The questions which now arrises is: Is it intended that flock is done by one
thread and the others should go on processing, i.e.  do you expect that
flock() or fcntl() block only the current thread and not the whole process?
When you expect this, it seems to be clear that the stuff blocks the way it
does on user-space threading environments.

You said, the stuff was developed under Linux and uses kernel-space threads,
so there the problem might be not occur. Was apache-pthread or
apache-mpm-dexter ever tried on a user-space threading environment?

Finally, if my determined runtime procedure is correct, how can we solve the
problem? I currently think this can be only solved in user-space by the
USE_PTHREAD_SERIALIZED_ACCEPT variant. But for this one needs a really cool
pthread library which supports _POSIX_THREAD_PROCESS_SHARED and currently I do
not know of any freely available one which does this. I've started work on
this for GNU Pth with the help of MM, but that's still unfinished... 

Hmmm... either my understanding of the hybrid process model is still not quite
correct, or I've overlooked an important part, or I'm right and the stuff
cannot work with the standard user-space threading environments :-( Please
prove me to be wrong!
                                       Ralf S. Engelschall

View raw message