Yeah, we've got to be inline with the HTTP Project - prefork is the
default on unix systems, so we have to abide by it...
So I guess the solution is that we need to reserve two locks instead of
just one?
Grisha
On Thu, 23 Jun 2005, Jim Gallacher wrote:
Nicolas Lehuen wrote:
Hi Jim,
Until now, we suspected that the way global locks are handled could be
deadlock prone. You have just proved it.
I know that global locks are expensive on some systems, especially if
we want to use them in a multiprocess (forked) environment. That's why
we are forced to have such a small pool of global locks.
On the other hand, in a multithreaded environment, locks which are
valid for the whole process are not so expensive ; indeed, we can
create a whole bunch without bringing down the system (think about
Java where all object potentially have a monitor which is equivalent
to a lock).
I think this is a strong incentive to abandon the forked model and go
for the multi-threaded model (or the mono-threaded, asynchronous one).
For concurrency control, the forked model does not scale, apparently.
It would make life easier I suppose, but we are stuck with the fact that
apache provides several different mpm models that need to be supported.
Jim
