Actually, I don't think an app would ever want to specify CROSS_PROCESS as it is currently implemented, since it is not portable. How would an app developer create a lock that will _never_ serialize in-process threads, and _only_ synchronize across processes?
Maybe we're trying to mix too much into this part of APR? We have threaded vs single, multiple lock scopes, multiple lock types, multiple implementations on multiple platforms. All this under one set of functions -- apr_lock_*(). (But this is a whole other discussion :). You are correct that this will affect prefork, but only when built against a threaded APR, and only on platforms where the crossplatform lock mechanism is not global. And even then it will only mean that the lock mechanism is implemented with two locks instead of one. I see your point, but I see this is a tradeoff between API clarity and crossplatform consistency, and a small amount of efficiency in isolated cases. -aaron On Tue, Jul 03, 2001 at 07:05:19AM -0400, Jeff Trawick wrote: > Hmmm... > > A non-threaded app needs to serialize access to a resource across > multiple processes. > > This non-threaded app builds/runs against a threaded APR. > > Before this patch: > > we only need one lock on many platforms (app specifies > APR_CROSS_PROCESS) > > After this patch: > > we need two locks on many platforms (cross process and intra > process) > > Isn't this going to bite prefork? > > -- > Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: > http://www.geocities.com/SiliconValley/Park/9289/ > Born in Roswell... married an alien...
