[lkml]   [2002]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Futex Asynchronous Interface
Rusty Russell wrote:
> In message <> you wri
> te:
>> this makes no sense:
>>D: This changes the implementation so that the waker actually unpins
>>D: the page. This is preparation for the async interface, where the
>>D: process which registered interest is not in the kernel.
>>Whazzup? The closing of the fd will unpin the page, the waker has no
>>reason to do so. It is very much against the linux philosophy (and a
>>design disaster anyway) to have the waker muck with the data structures of
>>anything waiting.
> Good catch: now the fd is a "one-shot" thing anyway, making close
> unpin the page makes more sense. Tested patch below (against 2.5.21).
> FYI: I already violate this philosophy as I remove the waiter from the
> queue when I wake them: this allows them to tell that they were woken
> (waker does a list_del_init() on the waiting entry, so waiting knows
> if (list_empty()) I was woken).
> It would be more natural for the waiter to examine the futex value,
> and if it's still unchanged go back to sleep. But this makes
> assumptions about what they're using the futex value for. For
> example, we "PASS_THIS_DIRECTLY" value into the futex. This requires
> that one (and ONLY one) process waiting actually wakes up.
> This is why coming up with a primitive which allowed us to build posix
> threads and fair queueing as well as "normal" unfair semantics took so
> damn long.

What are the plans on how to deal with a waiter when the lock holder
dies abnormally?

What about sending a signal (SIGTRAP or SIGLOST), returning -1 and
setting errno to a reasonable value (EIO?)

I couldn't find anything in susv3

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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