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, Jonathan Marler
> wrote:
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_ctl.
int epoll_ctl
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, Jonathan Marler wrote:
>>
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 de
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 s
