On Tue, Jun 15, 2004 at 11:42:28AM +0200, Justin Erenkrantz wrote: > --On Monday, June 14, 2004 8:02 AM -0400 [EMAIL PROTECTED] 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. joe
