++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, [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 > > >
