httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: APR locks
Date Fri, 01 Oct 1999 18:18:57 GMT
On Fri, Oct 01, 1999 at 08:58:28AM -0400, Bill Stoddard wrote:
> The definition of ap_lock_t on Unix depend on the serialization #define
> (PTHREAD, FCNTL, FLOCK, etc). ap_lock_t must contain the undelying lock
> typedefs, e.g., on Win32, a mutex (cross process) and a critical section
> (intra process). This structure also requires a runtime check each lock
> operation to determine the lock scope. Too many details hidden which can
> lead to subtle bugs. I'm thinking a seperate APIs for inter-process locking
> and intra-process locking is preferable. The underlying implementation would
> be simpler and it will be obvious looking at the code what kind of lock is
> being used.

Part of the reason Ryan did it this way is that at various times I
wanted the ability to specify:

- cross-process+thread locking required
- cross-process locking, thread locking optional(*)
- cross-proces locking, all threads allowed in
- thread locking, cross-process optional(*)

and so on. So, we came up with the current system as a way to support
these various schemes while trying to be as efficient as possible. If
I wanted the first lock scope above, I'd rather have APR use one
cross-process pthread lock if it's available, rather than having two
locks just because I was forced to by the API.

But, if splitting up the lock API will make up for sometimes adding
extra mutex calls, then I like the idea. Right now, the threaded Unix
MPMs are only using the (*) locks above anyway, so splitting up the
API can only speed things up.

Manoj Kasichainula - manojk at io dot com -
"Yes, I'm Linus, and I'm your God" -- Linus Torvalds, Linux Expo '98

View raw message