apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: Proc mutex re-org
Date Tue, 15 Jun 2004 13:55:18 GMT

It could work, you are correct.  I wasn't trying to fix that problem, I
was trying to get _any_ mutexes to work with proc_create.  If we have
other bugs that some mutexes do work and others don't, then thats fine,
but those are other bugs that can easily be worked out whenever.  The API
is what I cared about fixing.

Regardless, my time is now gone for this issue.  The new kid isn't
sleeping yet, and I am back at my day job.  So, I am really against trying
to release 1.0 without a fix for this, but I no longer have time to work
on it.


On Tue, 15 Jun 2004, Justin Erenkrantz wrote:

> --On Monday, June 14, 2004 8:02 AM -0400 rbb@rkbloom.net wrote:
> > Read the patch and find out.   :-)  FCNTL is tested in the test program,
> > and it _does_ work, but only as a fork() mutex.  flock was the one I
> > chose, just because I needed one that would work as a proc_exec mutex,
> > and fcntl doesn't.
> Why wouldn't fcntl() work as a proc_exec mutex?  I don't see any reason why it
> shouldn't - my question was precisely because your patch ignored it.  And, in
> my strawman patch, fcntl() worked fine with modifications to how we acquire
> fcntl() - flock() isn't very portable or even very reliable on most OSes.
> I do have some reservations with overloading the child_init in such a manner
> like you suggest.  It seems you are always going to re-open the file even if
> we are a fork()d child with the mutex variable still open from the parent.
> I'd rather we had a mechanism to only open the extra descriptor when it is
> absolutely required - i.e. the user explicitly wants proc_exec.  -- justin

View raw message