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 <t...@herbertland.com> wrote: > On Sat, Sep 19, 2015 at 8:30 AM, Jonathan Marler <johnnymar...@gmail.com> > 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(int epfd, int op, int fd, struct epoll_event *event); > >> On Sat, Sep 19, 2015 at 9:21 AM, Eric Dumazet <eric.duma...@gmail.com> 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 descriptor needs to be serviced. Since the >>>> epoll api has no way of storing this context, it has to be looked up >>>> using the descriptor, which will take more time/memory as the number >>>> of descriptors increase. The memory saved from omitting this context >>>> can't be worth it since you'll have to allocate the memory in the >>>> application anyway, plus you're now adding the extra lookup. >>>> >>>> This "lookup" problem has always existed in multi-plexed applications. >>>> It was impossible to fix with older polling interfaces, however, since >>>> epoll is stateful, it provides an opportunity to fix this problem by >>>> storing the descriptor context in epoll's "state". What was the reason >>>> for not doing this? Was it an oversight or am I missing something? >>> >>> >>> typedef union epoll_data >>> { >>> void *ptr; >>> int fd; >>> uint32_t u32; >>> uint64_t u64; >>> } epoll_data_t; >>> >>> struct epoll_event >>> { >>> uint32_t events; /* Epoll events */ >>> epoll_data_t data; /* User data variable */ >>> } __EPOLL_PACKED; >>> >>> >>> >>> Application is free to use whatever is needed in poll_data_t >>> >>> You can store a pointer to your own data (ptr) >>> Or a 32 bit cookie (u32) >>> Or a 64 bit cookie (u64) >>> >>> (But is an union, you have to pick one of them) >>> >>> Nothing forces you to use 'fd', kernel does not care. >>> >>> >>> >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html