Re: [PATCH] POSIX message queues - syscalls & SIGEV_THREAD

[Jamie Lokier <jamie@shareable.org>]

Krzysztof Benedyczak wrote:
> I'm afraid not ;-). In our case there can happen two situations after
> setting notification: 1) (normal) notification event that have to be
> serviced 2) cancellation of notification - when thread which some time ago
> set notification resigns from it. In general it is only important that we
> need a possibility to "signal" userspace with 2 different values.

You can just store the different values in userspace before signalling
the futex wakeup, can't you?

> >     5. If any are different, close() the fds and return "did not sleep".
> ------>hole
> >     6. Call poll() on the list of fds to wait until one becomes ready.
> >     7. close() the fds and return "woken".
> 
> If I understand you in the right way - yes it is important. The very
> simple situation - we have two futexes. One wakeup on first
> futex happen between 5. and 6. On the futex number 2 never. Or after an
> hour.

You are setting the first futex's word in userspace prior to the first
futex wakeup, right?  Either 5 will detect that and return
immediately, or it will reach 6 and the poll() returns immediately.
No hole there.

( The async token passing flaw is that the _waker_ loses track of how
many succesful wakeups it has sent; this is used by some
implementations of fair semaphores, among other things.  That might be
relevant to POSIX message queues but I do not see that it's relevant
to the two futex problem you described. )

-- Jamie