lkml.org 
[lkml]   [2006]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [take14 0/3] kevent: Generic event handling mechanism.
From
From: Ulrich Drepper <drepper@redhat.com>
Date: Sun, 27 Aug 2006 14:03:33 -0700

> The biggest problem I see so far is the integration into the existing
> interfaces. kevent notification *really* should be usable as a new
> sigevent type. Whether the POSIX interfaces are liked by kernel folks
> or not, they are what the majority of the userlevel programmers use.
> The mechanism is easily extensible. I've described this in my paper. I
> cannot comment on the complexity of the kernel side but I'd imagine it's
> not much more difficult, just different from what is implemented now.
> Let's learn for a change from the mistakes of the past. The new and
> innovative AIO interfaces never took off because their implementation
> differs so much from the POSIX interfaces. People are interested in
> portable code. So, please, let's introduce SIGEV_KEVENT. Then we
> magically get timer notification etc for free.

I have to disagree with this.

SigEvent, and signals in general, are crap. They are complex
and userland gets it wrong more often than not. Interfaces
for userland should be simple, signals are not simple. A core
loop that says "give me events to process", on the other hand,
is. And this is what is most natural for userspace.

The user can say when he wants the process events. In fact,
ripping out the complex signal handling will be a welcome
change for most server applications.

We are going to require the use of a new interface to register
the events anyways, why keep holding onto the delivery baggage
as well when we can break free of those limitations?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-28 04:01    [from the cache]
©2003-2011 Jasper Spaans