lkml.org 
[lkml]   [1997]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: File locking anomaly under 2.0.30
Date
  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.


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.205 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site