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. Ryan On Tue, 15 Jun 2004, 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. > > 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 >
