Messages in this thread | | | Date | Tue, 11 Mar 2003 10:20:38 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch, rfc] lt-epoll ( level triggered epoll ) ... |
| |
On Tue, 11 Mar 2003, bert hubert wrote:
> On Mon, Mar 10, 2003 at 12:15:25PM -0800, Davide Libenzi wrote: > > > 2) Existing apps using poll/select can easily be ported usinf LT epoll > > This is a big thing. I created a webserver based on MTasker > (ds9a.nl/mtasker) that used select, poll or epoll and it was very hard to > abstract this properly as level and edge semantics differ so wildly. > > 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.
> > 1) We leave epoll as is ( ET ) > > 2) We apply the patch that will make epoll LT > > 3) We add a parameter to epoll_create() to fix the interface behaviour at > > creation time ( small change on the current patch ) > > > > With 2) and 3) there are also man pages to be reviewed to be posted to > > Andries. Comments ? > > I'd vote for 2.
I received a bunch of private emails ( ppl that are using ET epoll ) asking me to have both behaviours. The code require no more than 10 lines of code to give both possibilities. We have two options in doing that :
1) We add a parameter to epoll_create() that will set the interface behaviour at creation time :
#define EPOLL_ET (1 << 0)
int epoll_create(int size, int flags);
2) We can go at fd granularity by leaving the API the same, and we define :
#define EPOLLET (1 << 31)
... events = EPOLLIN | EPOLLET;
What do you think ?
- Davide
- 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/
| |