apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: [PATCH] Strawman at fixing disjoint process locking
Date Tue, 08 Jun 2004 12:35:43 GMT


On Tue, 8 Jun 2004 rbb@rkbloom.net 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


Mime
View raw message