Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 19 Jun 2000 15:28:24 -0400
Message-Id: <200006191928.PAA24095@k5.localdomain>
From: Jeff Trawick <trawick@ibm.net>
To: new-httpd@apache.org
Subject: possible APIs for no-wait APR locks
Reply-to: trawick@ibm.net

All of the underlying lock mechanisms used by APR support no-wait
locks, but APR doesn't expose this functionality.  I'd like to get
this implemented, as it is helpful for something I wanted to play
with.  (I could hack something up pretty quickly, but I think other
folks could use it so I'd rather spend the time now getting it in
APR than hacking around with the current code, only to throw it away
later.)

Here are a few possibilities for API changes.  I prefer plan a.  I
have no preference among b and c.  Other ideas?

plan a:

  ap_create_lock() interface unchanged

  ap_lock() interface unchanged

  add new ap_set_lock_nowait() function
  (ap_set_lock_wait() could possibly be added in the future if
  somebody needs it)

plan b:

  add new lock type parameter APR_MUTEX_NOWAIT to ap_create_lock();
  APR_MUTEX is exactly like APR_MUTEX except that all ap_lock() calls
  are no-wait

  (By the way... what the heck is APR_READWRITE supposed to be?  One
  caller of ap_create_lock() specifies it, but the implementation is
  the same.)

plan c:

  add new function ap_try_lock() which is a no-wait flavor of
  ap_lock()

  This is nice, but the logic to check the current blocking state of
  the lock file (fcntl() and flock()) and possibly toggle it would be
  intermingled with the locking code.

Comments?
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...