Messages in this thread | | | From | (Matthias Urlichs) | Subject | Re: File locking anomaly under 2.0.30 | Date | 24 Jul 1997 23:02:47 +0200 |
| |
"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?
| |