lkml.org 
[lkml]   [2003]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch, rfc] lt-epoll ( level triggered epoll ) ...
On Fri, Mar 14, 2003 at 02:16:34PM -0800, Davide Libenzi wrote:
> On Fri, 14 Mar 2003, Jonathan Lemon wrote:
>
> > In article <local.mail.linux-kernel/Pine.LNX.4.50.0303140845480.1903-100000@blue1.dev.mcafeelabs.com> you write:
> > >On Fri, 14 Mar 2003, Valentin Nechayev wrote:
> > >
> > >> Tue, Mar 11, 2003 at 14:27:50, jamie wrote about "Re: [patch, rfc]
> > >lt-epoll ( level triggered epoll ) ...":
> > >>
> > >> > Actually I think _this_ is cleanest: A three-way flag per registered
> > >> > fd interest saying whether to:
> > >> >
> > >> > 1. Report 0->1 edges for this interest. (Initial 1 counts as an event).
> > >> > 2. Continually report 1 levels for this interest.
> > >> > 3. One-shot, report the first time 1 is noted and unregister.
> > >> >
> > >> > ET poll is equivalent to 1. LT poll is equivalent to 2. dnotify's
> > >> > one-shot mode is equivalent to 3.
> > >>
> > >> kqueue can do all three variants (1st with EV_CLEAR, 3rd with EV_ONESHOT).
> > >>
> > >> So, result of this whole epoll work is trivially predictable - Linux will have
> > >> analog of "overbloated" and "poorly designed" kqueue, but more poor
> > >> and with incompatible interface, adding its own stone to hell of
> > >> different APIs. Congratulations.
> > >
> > >See, this is a free world, and I very much respect your opinion. On the
> > >other side you might want to actually *read* the kqueue man page and find
> > >out of its 24590 flags, where 99% of its users will use only 1% of its
> > >functionality. Talking about overbloating. You might also want to know
> > >that quite a few kqueue users currently running on your favourite OS, are
> > >moving to Linux+epoll. The reason is still unclear to me, but I can leave
> > >you to discover it as exercise.
> >
> > FUD. You should know that in the normal case, kq users don't use any
> > flags, but they are available for those people who are doing specific
> > things. But I bet you knew that already and just want to slam something
> > that isn't epoll.
>
> Please, consider reading the message that generated the response before
> generating superfluous noise. Expecially those "overbloated" and "poorly
> designed" thingies. In my books overbloat is the presence of features that
> 99% of users simply ignore.

I've read the entire thread.

I'm responding to your hyperbole about "XXX flags", which is pure
exaggeration. I might as well say that epoll is "limited" and
"single-purpose", since it is not capable of doing the same things
that kqueue can do. In my book, engineering should make the common
case fast, and the uncommon case possible. You seem to be ignoring
the latter.

If you want to call those features you don't use, "bloat", fine. But
they *are* useful to many (>> 1) people, and they were added because
there was no other way to solve their problem. You should see the
laundry list of items/features/extensions/flags I declined to add, usually
because they were too special-purpose.
--
Jonathan
-
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: 2005-03-22 13:33    [W:0.028 / U:2.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site