At 07:42 AM 6/4/2004, Joe Orton wrote: >On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote: >> I took a look at the locking problem, and I think it can be fixed >> rather trivially. This is a minor problem in that it only affects the >> case where the child doesn't share memory addresses - such as when >> happens by using apr_proc_create. Hence, adding an 'apr_*_mutex_join' >> could solve the problem. > >But that model only works for fcntl and flock mutexes: the other three >mechanisms on Unix (as currently implemented) simply cannot be used for >synchronisation between processes which did not inherit a particular >apr_proc_t structure. > >I think that we're looking for solutions to a non-problem here: the >apr_proc_mutex interface is only useful on platforms with fork(). So >let's surround the header with #if APR_HAS_FORK and be done with it?
No, the named flavors are useful on platforms w/o fork. Only the anonymous ones are useless except with fork. >If you want to do portable synchronisation between two independent >processes, you can use files and apr_file_lock(), right? No, that's most certainly not a desirable choice for win32. However, I'm a little scared that folks rely on apr_proc_mutex assuming it either does or does not lock across threads of the same process. With apr_global_mutex this issue is a no-op. I'm wondering what the portability argument is for a mutex which may or may not respect threads. Bill
