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