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-----