same on HP-UX also.. This is how it looks :
/* Cross process serialization techniques */ /* #undef USE_FLOCK_SERIALIZE */ #define USE_SYSVSEM_SERIALIZE 1 /* #undef USE_FCNTL_SERIALIZE */ /* #undef USE_PROC_PTHREAD_SERIALIZE */ /* #undef USE_PTHREAD_SERIALIZE */
/* #undef POSIXSEM_IS_GLOBAL */ /* #undef SYSVSEM_IS_GLOBAL */ /* #undef FCNTL_IS_GLOBAL */ /* #undef FLOCK_IS_GLOBAL */
oh well...sigh... I guess we're stuck with using double locks for now, either as in your patch or as in the apr_global_mutex_xxx functions. I can configure Apache with --disable-threads when I benchmark with prefork and get it back down to one lock. I will be on vacation for the rest of the year after tomorrow, so I'd prefer that someone else follow up on this.
Longer term, Dave Hansen whom I work with at IBM had a couple of intriguing ideas for the SPECWeb99 post log. One is to implement it in shared memory. The current record counter is updated using an atomic_add primitive. Once you do that, you can use the answer as an index into an array of log records and no other threads will access that particular record. A complication is how to implement command/Fetch. Dave has an implementation which uses a separate daemon program to retrieve the log.
Dave also asked me if there would be a way to use Apache's regular logging functions for the SPEC post log, and cut down on the number of opens and closes on the post log file. That's an interesting idea. If mod_specweb99 opened the post log during the post_config hook, or something similar, and the child processes all inherited the post log fd, they could just write to it. The problem would be the current record counter and the record number at the beginning of each log record. We could use a shared memory variable updated with atomic_add here too, or maybe pipe the post log to a utility which prepends the record number. I took a quick look at the SPECWeb99 run rules, and they seem to be flexible on how you actually implement the post log.
Greg
