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? -- 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
