apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] Strawman at fixing disjoint process locking
Date Mon, 07 Jun 2004 18:46:27 GMT
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.


View raw message