At 08:45 PM 6/12/2004, [EMAIL PROTECTED] 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
