apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Proc mutex re-org
Date Sun, 13 Jun 2004 15:41:01 GMT
At 08:45 PM 6/12/2004, rbb@rkbloom.net wrote:

>OK, here is the proc mutex re-org.  This is ugly, but it passes all of the
>tests, using both fork and proc_create.  The only problem with this patch,
>is that it doesn't do the configure magic to actually setup FORK_DEFAULT
>and PROC_CREATE_DEFAULT.
>[...]
>+    APR_LOCK_FORK_DEFAULT,       /**< Use the default process lock when using apr_proc_fork
*/
>+    APR_LOCK_PROC_CREATE_DEFAULT /**< Use the default process lock when using apr_proc_create
*/
> } apr_lockmech_e;

Ryan,

  It seems these can be even more abstracted, can I suggested that the
final change uses APR_LOCK_ANONYMOUS_DEFAULT for forked and 
other non-shared applications, and APR_LOCK_NAMED_DEFAULT 
for those applications which much attach to another processes' lock?

  _proc_create and _fork seem to imply they are more specialized than
they really are, but as your STATUS entry pointed out, they require
different mechanics.

  Of course anonymous may be implemented as a named lock on those
platforms which require a name, but apr should (already?) also generate
a random name for such locks on the platforms which don't prefer to
use any unnamed locking method.

  With this slightly more abstract convention, totally +1 to your patch.

Bill



Mime
View raw message