On Thu, Jun 21, 2001 at 02:20:11PM -0400, Jeff Trawick wrote: > Aaron Bannert <[EMAIL PROTECTED]> writes: > > > I apologise if this was already discussed, but I'm curious why there > > are three scope types instead of just two? > > > > (from include/apr_lock.h:103) > > > > * @param scope The scope of the lock to create, one of: > > * <PRE> > > * APR_CROSS_PROCESS lock processes from the protected area. > > * APR_INTRAPROCESS lock threads from the protected area. > > * APR_LOCKALL lock processes and threads from the > > * protected area. > > * </PRE> > > > > Also the note further down: > > > > * @tip APR_CROSS_PROCESS may lock both processes and threads, but it is > > * only guaranteed to lock processes. > > > > > > I'm just curious if there actually are scenarios where an apr_lock_t > > is usable across processes but not in the same process? > > yes... On various systems the syscalls we use for an > APR_CROSS_PROCESS lock will not block out other threads in same > process as the thread holding the lock though they will block out > threads in other processes. > > I guess that is what you mean by "is usable." If you mean "when > would it be okay to use a lock that doesn't lock out other threads in > the same process" then that depends on your application.
[I hope you don't mind that I have replied back to the list] I was asking about the apr implementation, nothing specific to an application. Does anyone know which platforms present this kind of behavior (and what are the underlying mechanisms -- flock, pthread et al, etc?)? I'm looking through this locking code and it seems a bit tangential to other lock implementations I've seen. Normally the lock knows nothing about it's scope of accessability (intra-process vs. inter/cross-process), since that is taken care of the lock owner. Typically that owner would place the apr_lock_t in the same physicaly location as the data it's locking. In addition, it seems we're mixing provisional and mandatory locks under the same API. Before I propose any alternative solutions, I'd like to understand what the current implementation of locks are being used for. Is there a need to provide a single lock API for transparently handling provisional and mandatory locks? Furthermore, would it be difficult for an application using locks to specify its locking requirement in a platform-independent way that still meets the scope requirements of the data it's trying to protect? -aaron
