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 Sun, 13 Jun 2004 16:00:22 GMT
At 07:35 AM 6/8/2004, rbb@rkbloom.net wrote:
>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.

Exactly.  I think we are overloading apr_*_child_init to suggest it's also 
a join.  child_init suggests a very specific relation to fork.

Two functions, one for the forked-child, and one for the created process
(truly a join operation) are preferable to confusing, functional overloading.

>> > >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.

No, the anonymous ones are also very useful for single-process applications.
If there is no need to fill up the object name hashes in the kernel, then don't.

With that said, thanks for your efforts, Ryan, in bringing this to a close.
The only open issue I see would be to split the child_init (a fork'ed process'
access to a lock) from the join (any create'ed or disjoint processes access
to a common lock.)  Because most unix's can do both, this seems like
a pretty critical distinction.

Note that child_init() presumes a pointer to a valid apr_*_mutex_t, while
the join()'s flavor would always allocate a new apr_*_mutex_t based on
the lock's name.

Bill  


Mime
View raw message