apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Proc mutex re-org
Date Tue, 15 Jun 2004 09:59:08 GMT
On Tue, Jun 15, 2004 at 11:42:28AM +0200, 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.

Changing the fcntl_create to not unlink() introduces an unnecessary
"server won't restart after unclean shutdown" issue since the file is
created using O_EXCL.  So at least it would be good to remove the O_EXCL
too if removing the unlink() if going that route.

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

Agreed, your _join method seems like a better approach.  Always
re-opening the file in the child introduces the race which flock suffers
from where the parent deletes the file before a child re-opens it.


View raw message