Messages in this thread | | | Date | Fri, 25 Jul 1997 23:38:57 +0100 (BST) | From | Bryn Paul Arnold Jones <> | Subject | Re: File locking anomaly under 2.0.30 |
| |
-----BEGIN PGP SIGNED MESSAGE-----
On 25 Jul 1997, Matthias Urlichs wrote: > Bryn Paul Arnold Jones <bpaj@gytha.demon.co.uk> writes: > > So we have two cases, the child has a copy of the file descriptors, when > > the POSIX fork semantics should apply to locks; and when the child has the > > same file descriptors as the parient when POSIX fork semantics should not. > > > The POSIX fork semantics emphatically do not apply to locks. A child > process doesn't inherit a parent's lock. >
Yes, but POSIX fork semantics shouldn't apply, as the child thread/process isn't a forked child, but a clone()d child (ok, I know fork is done via clone), and can shair the _same_ descriptors as the parient, not just copies of the descriptors (ie the child really can close the parients filedescriptors).
> > We already have such a flag, CLONE_FILES, where the parient and child > > share there filedescriptors. > > > That flag doesn't apply to locks. The kernel lock struct has an explicit > field fl_owner which is a pointer to the process which holds the lock. >
Ok, but perhaps it should point to a list of pids that own the lock.
Currently with a userspace thread libary (one process scheduling threads withing its time slice) threads get to read/write (or otherwise access) a file locked by any thread, but with a clone() based thread libary, threads would only be able to access files they had locked them self (ok, so it's a niggle... ;).
Bryn - -- PGP Pub key http://www.gytha.demon.co.uk/pubkey.asc ID: 1024/30AF2D69 On-line, adj.: FP: FC 4E 41 9E 64 C3 AB 28 A3 5A 57 F8 CC D9 A7 B8 The idea that a human being should always be accessible to a computer.
-----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Probably (spelt
iQCVAwUBM9krCOsaGi8wry1pAQEFogP/QzqjcGeoaskcbR46bSvtGl456Q86q0kh leOaJrnLwDWgprIx2P5upFKTyyTUZadY+B3UbIpyeFSbYSXclksl0N3nIj7HpXyg d1t2XVf9NUs0UJp1BHKqfrEZlATUn3SI8+Ah074oYgMbANBjJNKC5NxozDibWnDL hFZhb0Go258= =YaUh -----END PGP SIGNATURE-----
| |