On Feb 9 21:38, Corinna Vinschen wrote: > On Feb 9 15:06, Steven Bardwell wrote: > > > How do you test that? You're calling fcntl(F_SETLKW) exactly once at > > > the start of your test application, but never again later. We're > > > talking advisory file locking here, so, where's the next fcntl call > > > waiting for the lock? > > > > > > I debugged your test app and the lock still exists after the spawn call. > > > > > > > > > > > > Corinna > > > > To test this, I start this program to check for the lock: > > Ok, I can reproduce it, but it's too late to debug this today. > > I have to say, though, that fcntl advisory locking is POSIX > functionality, while the spawn functions are not. In fact these dreaded > spawn entry points are rather old stuff, which hasn't been tested for a > long time. FWIW, advisory file locking has never been tested with them, > and the fact that it doesn't work as expected doesn't exactly disturb me.
I found the reason. On UNIX, an exec'ed process substitutes the calling process. When that happens, fcntl locks are inherited by the child. The internal implementation of exec and spawn share a lot of code. One of the code bits is the function which hands over the fcntl locks from parent to child. So after spawn, the owner of the lock is not the parent anymore, but the child process. After the child process died, the lock is abandoned and your 2nd test application rightfully claims that the file region is unlocked. I applied a patch which now differs between exec and spawn in the function handling the inheritance of locks in the child. If it has been spawned, it does not take over POSIX locks anymore, but rather it just gives them up in favor of the parent process. The current snapshot at http://cygwin.com/snapshots/ does not have this patch, but we will certainly produce another snapshot in the next few days. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpdQ_w8lWwHd.pgp
Description: PGP signature
