Re: epoll, missed opportunity?

2015-09-19 Thread Eric Dumazet
On Fri, 2015-09-18 at 22:51 -0600, Jonathan Marler wrote: > I'm curious why there wasn't another field added to the epoll_event > struct for the application to store the descriptor's context. Any > useful multi-plexing application will have a context that will need to > be retrieved every time a

Re: epoll, missed opportunity?

2015-09-19 Thread Jonathan Marler
The data field holds the file descriptor you are waiting on, it has to be the file descriptor, otherwise, how would the kernel know which file descriptor you are trying to wait on? On Sat, Sep 19, 2015 at 9:21 AM, Eric Dumazet wrote: > On Fri, 2015-09-18 at 22:51 -0600,

Re: epoll, missed opportunity?

2015-09-19 Thread Jonathan Marler
Wow how did I miss that?! This is perfect though, there is a context pointer! Finally my dream of a perfect polling interface exists in linux. Thanks so much for the quick response. On Sat, Sep 19, 2015 at 9:46 AM, Tom Herbert wrote: > On Sat, Sep 19, 2015 at 8:30 AM,

Re: epoll, missed opportunity?

2015-09-19 Thread Tom Herbert
On Sat, Sep 19, 2015 at 8:30 AM, Jonathan Marler wrote: > The data field holds the file descriptor you are waiting on, it has to > be the file descriptor, otherwise, how would the kernel know which > file descriptor you are trying to wait on? > fd is the third argument in

epoll, missed opportunity?

2015-09-18 Thread Jonathan Marler
I'm curious why there wasn't another field added to the epoll_event struct for the application to store the descriptor's context. Any useful multi-plexing application will have a context that will need to be retrieved every time a descriptor needs to be serviced. Since the epoll api has no way of