Re: [patch 14/22] pollfs: pollable futex

["Ulrich Drepper" <drepper@gmail.com>]

On 5/3/07, Davide Libenzi <davidel@xmailserver.org> wrote:
>
> I thought you were talking about the poll/epoll interface in general, and
> the approach on how to extend it for the very few cases that ppl asks for.
> but I see we're focusing on futexes ...

Futexes must be part of the whole approach.  If they cannot sanely be
integrated the whole approach is more than questionable IMO.


> I'm not sure if futexes are the best approach to do that, but a way for
> the user to signal an event into a main event loop is needed.

I haven't necessarily seen much of this demand and, as you pointed out
yourself, there is already a completely valid and POSIX compliant way
to achieve that.  The situation would be very different if you
couldn't reliably implement this.

I don't suggest this as a long term solution, it's neither nice nor
fast.  But it is a way to achieve the goal until a real soution comes
along.  Signals cannot serve as a justification for introducing these
new concepts.


> IMO it is better to leave futexes alone. They are great for syncronizing
> MT apps, but do not properly fit an fd-based solution. For that, something
> like eventfd is enough.

That's ridiculously short-sighted.  All objects upon which one can
wait must be unified.  This is possible.  The kevent interface gives
enough flexibility.


Let's just finish the design and implementation of the real solution.
Be it kevent (modified to meet the last comments, I think I still have
some myself), or something completely different which you can propose.
 Then all programs which really care about performance can use that
code.

If a program doesn't care about performance then they might just as
well use pipes in signal handlers.