Re: [patch, rfc] lt-epoll ( level triggered epoll ) ...

[Davide Libenzi]

On Wed, 12 Mar 2003, bert hubert wrote:

> On Tue, Mar 11, 2003 at 10:20:38AM -0800, Davide Libenzi wrote:
>
> > > Most programs will not abandon 'legacy' interfaces like poll and select and
> > > will only want to offer epoll in addition. Right now that is hard to do.
> >
> > I agree here. It took 15 minutes to port thttpd to LT epoll.
>
> Having level ability will massively speed up epoll adoption. By the way, was
> there a reason to go to edge in the first place?

Well, the first version of /dev/epoll was truly ET and it wasn't using
poll kernel hooks. With the usage of poll hook it became more affordable
to consider to have both ET and LT behaviours. ET would be my pick if I
have to start a new application from scratch anyway.

> > We add a parameter to epoll_create() that will set the interface behaviour
> > at creation time :
> ...
> > We can go at fd granularity by leaving the API the same, and we define :
> > 	#define EPOLLET (1 << 31)
>
> This last option would retain the current ABI *and* semantics for unchanged
> programs. I do wonder if there is a case where you'd want to run in mixed
> mode, however. But if the code to support mixed operation is truly trivial,
> I think we should not set policy from the kernel ('only do epoll in one
> mode') and leave it up to userspace to discover if there is a use for this.
>
> Anyhow, as a member of the kCowSay [1] association of userspace people
> meddling in the affairs of kernel coders, I vote strongly for having level
> triggered epoll on the kernel, with the ability to do mixed mode.

The patch I posted yesterday does the per-fd selectable ET/LT behaviour.
It ran fine on UP and 2SMP tonight, so I'm going to ping Linus for a merge
later today.

- Davide