apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: Proc mutex re-org
Date Sun, 13 Jun 2004 20:54:13 GMT

++1 to re-naming this way.  You guys know not to let me name things.
After I get some more feedback, I'll make this change (and possibly
others) and commit.

Ryan

On Sun, 13 Jun 2004, William A. Rowe, Jr. wrote:

> 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