APR_LOCK_DEFAULT ordering
Are people happy with the priority order of the accept mutex? Right now it's flock - sysvsem - fcntl - pthread. I think it should be pthread - sysvsem - fcntl - flock, which is what 1.3 has... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: APR_LOCK_DEFAULT ordering
On Wed, Mar 20, 2002 at 12:49:32PM -0500, Jim Jagielski wrote: Are people happy with the priority order of the accept mutex? Right now it's flock - sysvsem - fcntl - pthread. I think it should be pthread - sysvsem - fcntl - flock, which is what 1.3 has... Now that we're more confident in pthread, I'm a huge +1 for this second ordering. -aaron
Re: APR_LOCK_DEFAULT ordering
Jim Jagielski [EMAIL PROTECTED] writes: Are people happy with the priority order of the accept mutex? Right now it's flock - sysvsem - fcntl - pthread. I think it should be pthread - sysvsem - fcntl - flock, which is what 1.3 has... I realize everybody has jumped in and +1-ed you, but I don't see how you can compare the two orders which you stated above. I would express the current APR default selection (configure.in, line 1303) this way: 1st choice : fcntl 2nd: pthread 3rd: flock 4th: SysV sem I guess I'd vote for this order on systems where we don't have specific knowledge (e.g., use sysvsem for myOS = x): 1st choice: pthread 2nd choice: fcntl 3rd choice: SysV sem 4th choice: flock Also, in 1.3, I think there is a lot more explicit selection (i.e., case myOS use foo) that needs to be brought forward to APR so that these priorities are irrelevant (they should only be used when we don't have specific OS knowledge). Even if we think we ave the priorities the same between 2.0 and 1.3 it isn't really the same if we don't bring forward the cases where the priorities aren't even used. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: APR_LOCK_DEFAULT ordering
Jeff Trawick wrote: Jim Jagielski [EMAIL PROTECTED] writes: Are people happy with the priority order of the accept mutex? Right now it's flock - sysvsem - fcntl - pthread. I think it should be pthread - sysvsem - fcntl - flock, which is what 1.3 has... I realize everybody has jumped in and +1-ed you, but I don't see how you can compare the two orders which you stated above. I would express the current APR default selection (configure.in, line 1303) this way: 1st choice : fcntl 2nd: pthread 3rd: flock 4th: SysV sem But proc_mutex.c has the below: case APR_LOCK_DEFAULT: #if APR_USE_FLOCK_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_flock_methods; #elif APR_USE_SYSVSEM_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_sysv_methods; #elif APR_USE_FCNTL_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_fcntl_methods; #elif APR_USE_PROC_PTHREAD_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_proc_pthread_methods; #else return APR_ENOTIMPL; #endif And APR_LOCK_DEFAULT is what ap_accept_lock_mech is set to in mpm_common... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: APR_LOCK_DEFAULT ordering
Jim Jagielski [EMAIL PROTECTED] writes: Jeff Trawick wrote: Jim Jagielski [EMAIL PROTECTED] writes: Are people happy with the priority order of the accept mutex? Right now it's flock - sysvsem - fcntl - pthread. I think it should be pthread - sysvsem - fcntl - flock, which is what 1.3 has... I realize everybody has jumped in and +1-ed you, but I don't see how you can compare the two orders which you stated above. I would express the current APR default selection (configure.in, line 1303) this way: 1st choice : fcntl 2nd: pthread 3rd: flock 4th: SysV sem But proc_mutex.c has the below: case APR_LOCK_DEFAULT: #if APR_USE_FLOCK_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_flock_methods; #elif APR_USE_SYSVSEM_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_sysv_methods; If that were #if apr_HAVE_flock_serialize instead of apr_USE_flock_serialize then I'd believe you. But since it is referencing apr_USE_flock_serialize it is making use of the choices made at configure time, and thus the order of the logic here under APR_LOCK_DEFAULT is irrelevant. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: APR_LOCK_DEFAULT ordering
Jeff Trawick wrote: But proc_mutex.c has the below: case APR_LOCK_DEFAULT: #if APR_USE_FLOCK_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_flock_methods; #elif APR_USE_SYSVSEM_SERIALIZE new_mutex-inter_meth = apr_proc_mutex_unix_sysv_methods; If that were #if apr_HAVE_flock_serialize instead of apr_USE_flock_serialize then I'd believe you. By gum, you're right. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
