On Tue, 8 Jun 2004 [EMAIL PROTECTED] wrote:
> On Mon, 7 Jun 2004, William A. Rowe, Jr. wrote: > > > 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. > > There are reasons to use apr_proc_mutex, for example when you aren't using > threads. However, that really doesn't matter. This _isn't_ a no-op for > global_mutex. In fact, this exact same issue exists for global_mutex. > Take a look at the API for global_mutex, it is identical to the > proc_mutex_child_init API. Which means, it _doesn't_ work on Unix when > using apr_proc_create(). As for why we haven't caught it yet, it's > because that is yet another portion of the API which was committed without > a test to make sure it worked. I actually take this last part back. The reason we haven't caught the problem is that nobody noticed it. The current global_mutex test has us re-creating the mutex in the child process, just like we do with the proc_mutex test (which everybody agrees is wrong). I should have some time this afternoon or this evening to create a fix for this problem. I will fix it either today or tomorrow depending on how the kids sleep. Ryan
