Messages in this thread |  | | Date | Fri, 25 Aug 2000 16:35:29 +0200 | From | Andries Brouwer <> | Subject | Re: [FIX] Make deadlock detection work for file locking |
| |
On Fri, Aug 25, 2000 at 01:19:02PM +0200, Werner Almesberger wrote:
> Yes. My question was: what is a deadlock (in this context) ? > I.e. under what conditions must it _not_ return EDEADLK ? > > POSIX makes an attempt at describing it, but in rather vague > terms (see my original posting). Basically, the description > does not exclude EDEADLK already if a process holds any lock, > tries to get any other, and needs to sleep for it.
Generally POSIX error descriptions are not exhaustive. They go like (i) you must detect this type of error and return EWRONG if it happens, (ii) you may detect this type of error and return EBAD if it happens. But there may be unlisted error possibilities. In other words, when you get EINVAL from a POSIX routine then either it is an error described by POSIX under the EINVAL heading, or it is an error not described by POSIX.
Deadlock is not among the defined words.
Examples where POSIX explictly uses EDEADLK for other things than a common deadlock:
On lockf/flock: [EDEADLK] or [ENOLCK] The function argument is F_LOCK, F_TLOCK, or F_ULOCK, and the request would cause the number of locks to exceed a system-imposed limit.
The pthread_mutex_lock( ) function may fail if: [EDEADLK] The current thread already owns the mutex.
Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |