Messages in this thread | | | From | (Matthias Urlichs) | Subject | Re: File locking anomaly under 2.0.30 | Date | 25 Jul 1997 17:25:27 +0200 |
| |
Bryn Paul Arnold Jones <bpaj@gytha.demon.co.uk> writes: > > > > BTW, this points to a potential problem if we ever try to do async I/O with > > mandatory locks. Thread A locks something, then starts an async I/O > > request, which spawns Thread B, which fails to actually read/write the > > data because it doesn't own the lock. Ugh. > > Erm, I can't see a problem. An async I/O thread would share (not have a > copy of as with fork) all file descriptors, and I'd apply that to locks > too. > Currently, the Linux kernel does _not_ share POSIX locks between processes ecen if they use the same file descriptor.
> 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.
> 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.
| |