Messages in this thread | | | Subject | Re: File locking anomaly under 2.0.30 | Date | Fri, 25 Jul 1997 09:43:59 -0400 | From | Christopher Blizzard <> |
| |
In message <5r8ftn$reh$1@work.smurf.noris.de>, Matthias Urlichs writes: :"Theodore Y. Ts'o" <tytso@MIT.EDU> writes: :> Yup, you're quite right. POSIX states, :> :> "All locks associated with a file for a given process shall be :> removed when a file descriptor for that file is closed by that :> process or the process holding that file descriptor terminates. :> Locks are not inherited by a child process created using the :> fork() function." :> :By extension, this should hold for Linux' clone() too. Hence the patch. : :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. : :This is not a problem in a "genuine" threaded program because a thread :typically needs those data in order to continue and thus there's no need :for async I/O in the first place. However, a "normal" program which :requests some data and then tries to do something else until the data :arrive will lose. : :A possible solution would be to have a flag for clone() which gets stored :in the child's task_struct and which would instruct the kernel to use :current->pptr instead of current for lock checks. This would mean that :async-I/O threads wouldn't be managed with the standard threading code, :which (under LinuxThreads, anyway) collects all "work" threads under one :common managing thread, no matter which subthread actually spawned off :another thread, which may or may not be a problem. : :Better ideas, anybody? :
I think it's important here to seperate the concepts of a process and thread of execution within a process. When you do a clone() on a process you are only creating another thread of execution within the same process. When you do a fork() you are creating another thread of execution in a new process.
The snippit that Ted has referenced above should not apply to new threads within a single process. Unless POSIX says that new threads within the scope of a process shouldn't inherit locks, new threads should probably inherit them just like everything else. :)
--Chris
------------ Christopher Blizzard AppliedTheory Communications, Inc. http://odin.appliedtheory.com/ blizzard@appliedtheory.com ------------
| |