httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: Apache/pthread and locking problem
Date Wed, 11 Aug 1999 17:43:16 GMT
On Wed, Aug 11, 1999 at 04:54:32PM +0200, Ralf S. Engelschall wrote:
> 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?

Definitely.

Getting rid of the cross-process lock isn't a great solution, because
it's necessary to prevent the problem Dean noted at
<http://www.apache.org/docs/misc/perf-tuning.html> in the section on
accept serialization. In addition, since the threaded MPMs use a
server-wide pipe to signal child shutdown, getting rid of the accept
mutex could make restart less reliable.

We could try using the alternate solution listed in the paper (make
the socket non-blocking, so that the children that falsely drop into
accept() won't get stuck there), but it'll chew up CPU and wreck any
advantage that threads give us.

With the current socket APIs available, we need some way for the
processes to coordinate.

On Wed, Aug 11, 1999 at 07:03:51PM +0200, Ralf S. Engelschall wrote:
> I found it: In apache-pthread one just has to make sure that no
> USE_XXX_SERIALIZED_ACCEPT defines exists at all for a platform. Then the
> functions are nops and the beast works fine. Although it's still not really
> lightening fast...

The threaded servers really aren't that much faster than
process-based. The real benefit is scalability, and possibly a better
caching setup.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"The only thing worse than a few big, regulated telephone monopolies is
few, bigger, unregulated telephone monopolies." - Bob Metcalfe

Mime
View raw message