lkml.org 
[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.066 / U:0.556 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site