In article <local.mail.linux-kernel/[email protected]> 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.
--
Jonathan
On Fri, 14 Mar 2003, Jonathan Lemon wrote:
> In article <local.mail.linux-kernel/[email protected]> 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.
- Davide
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/[email protected]> 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
On Fri, 14 Mar 2003, Jonathan Lemon wrote:
> > > >> 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.
Let's start again. We were talking about APIs and there was a guy that
wrote that kqueue is better than epoll. I then replied that API are a
matter of personal opinions and that I prefer epoll, with other guys
pretty much following this taste. What I don't like of kqueue is 1)
multiplexing of a single funtion doing 23 different tasks 2) has many
options that A) increase code size B) are used by 2% of its users. This
was inserted in the context where I explicitly said that API are a matter
of personal taste. Then a guy came out with "overbloated" and "poorly
designed", and I replied to him. And no, you don't need 47 flags/options
to do things that people di for ages using poll(2). You're pushing code
inside the kernel when *many* of those things can be done in user space.
Why should the 98% of users using the bare minimum API to pay the price of
those extra features ? Let me guess you're going to say that those extra
features have no cost ... yeah right.
- Davide
On Fri, Mar 14, 2003 at 02:57:51PM -0800, Davide Libenzi wrote:
> On Fri, 14 Mar 2003, Jonathan Lemon wrote:
>
> > > > >> 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.
>
> Let's start again. We were talking about APIs and there was a guy that
> wrote that kqueue is better than epoll. I then replied that API are a
> matter of personal opinions and that I prefer epoll, with other guys
> pretty much following this taste. What I don't like of kqueue is 1)
> multiplexing of a single funtion doing 23 different tasks 2) has many
> options that A) increase code size B) are used by 2% of its users. This
> was inserted in the context where I explicitly said that API are a matter
> of personal taste. Then a guy came out with "overbloated" and "poorly
> designed", and I replied to him. And no, you don't need 47 flags/options
> to do things that people di for ages using poll(2). You're pushing code
> inside the kernel when *many* of those things can be done in user space.
> Why should the 98% of users using the bare minimum API to pay the price of
> those extra features ? Let me guess you're going to say that those extra
> features have no cost ... yeah right.
Yes, an API is a matter of personal taste, and I don't particularly like
epoll, but that isn't really relevant. What you seem to not understand
is that kqueue is an event framework into which you plug different filters,
which have different capabilities. You may not like this "multiplexing",
but that's part of the key to how kqueue works, and is THE reason it is not
just "Yet Another Notification Mechanism".
kqueue does not limit itself to the poll() interface, and hence can do
things that are simply not possible with poll. If you're just thinking
of epoll as a "faster poll", fine, but that's not what kqueue is, and
viewed from that context, yes, some things may appear as "bloat".
If you think that kqueue filters can be done in user space, I don't believe
you undersand the problem. Show me a single thing that an existing filter
does that you can do efficiently in userspace.
Kqueue itself (the core code) has only 6 user-settable flags:
- add/delete,
- enable/disable (these are optimizations)
- oneshot/clear (your new "tristate" flags).
Other than 'enable/disable', epoll is going to have to support these
in one form or another. Everything else is per-filter, and yes, if a
filter is not being used, there is *zero* cost, other than being linked
into the kernel. And yes, before you ask, I support dynamically loaded
filters, which futher extend kqueue's capabilities.
E.g.: do you want to perform multiple accept()s on a listening socket,
register the descriptors with kqueue, then return all of the new fd's
to userspace, all in one system call? Trivial, and actually being used
in a commercial product. Yes, *this* functionality can be done in userspace,
but at the cost of multiple system calls; which is one reason why it is
not part of a stock FreeBSD system.
So, where's the bloat? The "bloat" apparently comes from the fact
that kqueue is able to do much more than just "POLLIN|POLLOUT".
I don't intend to get into a long argument with you. It's clear to me
that epoll is designed to only solve a limited subset of problems that
kqueue does, which is fine. However, I do object when you say that kqueue
is has "too many flags", or is "bloated". That's like saying that the
linux kernel is bloated because it supports XXX different sound modules;
not all users will use all modules nor all features of a single module.
--
Jonathan
On Fri, 14 Mar 2003, Jonathan Lemon wrote:
> Yes, an API is a matter of personal taste, and I don't particularly like
> epoll, but that isn't really relevant. What you seem to not understand
> is that kqueue is an event framework into which you plug different filters,
> which have different capabilities. You may not like this "multiplexing",
> but that's part of the key to how kqueue works, and is THE reason it is not
> just "Yet Another Notification Mechanism".
I'm glad you seem to define kqueue "The Notification Mechanism", because
honestly, in my opinion "The Notification Mechanism" is what people
actually *uses* for real. Last time I checked "The Notification Mechanism"
is poll/select ( with kqueue pretty much down in the list ). Yes, maybe it
doesn't scale very well with high number of fds, but it does 99.99% of
what people needs. And the proof of this is that a huge number of
applications rely on poll/select. Why ? Beacause it's freakin' simple and
does the job. The new epoll interface aims to be that simple and to cover
the same needs that have driven developers to use select/poll. Who's right ?
Time will talk.
- Davide