apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Accept mutex
Date Fri, 22 Jun 2001 19:22:13 GMT
[ This probably doesn't belong on new-httpd except for the fact that we
  are talking about the accept mutex ]
[ I also think my mailer got wacked - resend... ]

On Fri, Jun 22, 2001 at 11:15:46AM -0400, Jim Jagielski wrote:
> Jeff Trawick wrote:
> > 
> > I think I'd rather see it fail.
> > 
> > If an app wants to back down to the default without informing the user
> > that they picked an invalid mechanism then it is just an extra couple
> > of lines.
> > 
> > rv = apr_lock_create(aaa, APR_MUTEX_SYSVSEM, bbb);
> >     rv = apr_lock_create(aaa, APR_MUTEX_DEFAULT, bbb);
> > }
> > if (rv != APR_SUCCESS) {
> >     /* handle failure to create a lock */
> > }
> > 
> Yeah, that's what I think should happen. If the user picks an
> unsupported mutex, Apache should pick the default and pop a
> message to error log.

+1.  Aaron Bannert and I were have a long conversation about the accept
mutex just yesterday.  Odd to see a post about it this morning.  =)

The types we discussed were: mutex, semaphore, rwlocks, conditionals.

We came to about the same conclusion - you can "downgrade" the lock to
something that is supported.  In fact, Stephens has code for
implementing readwrite locks on top of mutexes (pthread mutexes, but I
imagine that it can be generalized to however we implement "mutexes" 
in APR).

Semaphore and mutex are almost identical, but some platforms have 
specific code for mutex (think POSIX).  We've already got rwlocks 
(for Unix) and we've been discussing conditionals on this list in 
the last few days.  The thing is there is no way to differentiate
between a mutex and semaphore in APR right now.

There are also a few ways to implement mutexes (file-backed - fcntl,
etc, memory-backed - pthread, etc.).  I'm not sure there is a need to
say exactly which type of mutex you need - let APR pick the best mutex,
but maybe performance testing will prove that they may need to be an
option to say that we want a fcntl() backed mutex rather than a POSIX
mutex (what is being suggested).  However, I think just picking the 
type of lock may be sufficient (i.e. mutex, semaphore, etc.).

However, to add these, it might be worth it to revamp the APR lock API.
But, yeah, the developer needs to be able to specify which lock they
want.  If it isn't available on their platform, we can try and be nice
and provide something similar in functionality (i.e. implement a
readwrite lock in terms of a mutex, etc.).

And, Aaron and I discussed that rwlocks *might* provide a simple way of
removing our shutdown POD/signal nightmare.  We've used a POSIX rwlock 
before on a previous project to shutdown children.  The parent holds 
the write lock when it needs to stem the request flow (because it
received a signal) and each child attempts to obtain a read lock 
before it does something - aka before we hit the accept call.  The 
only thing to consider about rwlocks is that it might not yet be 
portable, but it becomes *very* clean.  Something to toss around.
-- justin

View raw message