On 5/3/07, Davide Libenzi <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
