[lkml]   [2003]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [patch, rfc] lt-epoll ( level triggered epoll ) ...
On Tue, 11 Mar 2003, Giuliano Pochini wrote:

> On 10-Mar-2003 Davide Libenzi wrote:
> >
> > During the last three months I spent considerable amount of time explainig
> > developers how edge triggered APIs works, and how to use epoll inside
> > their apps. It's time for me to face the reality, that is that:
> >
> > 1) developers not quite understand ET APIs
> > 2) most existing apps are written using LT APIs
> 1) is easily solvable writing a good FAQ. "Developers" who really
> can't undestand edge triggered APIs will continue to use poll().
> If ET il faster than LT, tell people to stop whining and to learn
> the API. Otherwise choose LT, mainly because of 2), but also
> because ET API is more subtle bug prone.

Believe me, many don't understand ET APIs. The epoll(4) man page tries to
answer to many questions but still it's not easy to wipe LT behaviour from
developers brain. On the other side, the merging of epoll inside the
kernel will have to have the goal to be actually and actively used by
developers. Due to the initial epoll architecture it was extremely easy to
have LT epoll and, right now, it has almost no cost to support both
behaviours. My current thought is to have the epoll user to choose the
behaviour on a per-fd basis, using a new EPOLLET event flag. I'm obviously
open to better suggestions ...

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.096 / U:2.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site