Curt Sampson <[EMAIL PROTECTED]> wrote: > At any rate, it seems to me highly unlikely that, since the child has > the *same* descriptor as the parent had, that the lock would > disappear.
It depends on the lock function. After fork(): o with flock() the lock continues to be held, but will be unlocked if any child process explicitly unlocks it o with fcntl() the lock is not inherited in the child o with lockf() the standards and manual pages don't say Boring reference material follows. flock ===== >From the NetBSD manual page: NOTES Locks are on files, not file descriptors. That is, file descriptors du- plicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. The Red Hat Linux 8.0 manual page has similar wording. (No standards to check here -- flock() is not standardised in POSIX, X/Open, Single Unix Standard, ...) fcntl ===== The NetBSD manual page notes that these locks are not inherited by child processes: Another minor semantic problem with this interface is that locks are not inherited by a child process created using the fork(2) function. Ditto the Single Unix Standard versions 2 and 3. lockf() ======= The standards and manual pages that I've checked don't discuss fork() in relation to lockf(), which seems a peculiar ommission and makes me suspect that behaviour has varied historically. In practice I would expect lockf() semantics to be the same as fcntl(). Regards, Giles ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly