Well, why not keep the 32 session locks for sessions, and add something to the locking API so that we can create dedicated locks for dedicated usages (the session database lock, the PSP cache lock...) ?
The next time someone will need a dedicated lock, he will be tempted to rely on the current implementation, thus creating new potential for deadlocks... Regards, Nicolas 2005/6/24, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>: > > 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 > > >
