| |||||||||||||
EPOLL_CTL_DISABLE and multithreaded applicationsEPOLL_CTL_DISABLE and multithreaded applicationsPosted Oct 25, 2012 16:32 UTC (Thu) by happynut (subscriber, #4117)Parent article: EPOLL_CTL_DISABLE and multithreaded applications
Perhaps I'm missing something, but it seems like the proposed solution is to add a synchronous call to control an asynchronous queue.
Couldn't this be solved with a flag (or an alternate version) of EPOLL_CTL_DEL to add an event to the queue reporting that the delete has been fully processed?
Then the caller of epoll_wait() could then clean up the remaining application's data structures, with no new locks required.
(Log in to post comments)
EPOLL_CTL_DISABLE and multithreaded applications Posted Oct 28, 2012 14:38 UTC (Sun) by kjp (subscriber, #39639) [Link]
How do you know 'what fully processed' means? Another thread could have been 'woken up' by the kernel, but hasn't gotten around to looking in your internal structures. If another thread gets the 'deleted processed' event, it could delete the data structure prematurely.
EPOLL_CTL_DISABLE and multithreaded applications Posted Oct 28, 2012 18:57 UTC (Sun) by happynut (subscriber, #4117) [Link]
I mean "fully processed" by the kernel, which is really the only issue; the application can (and indeed: must, even with the proposed EPOLL_CTL_DISABLE change) control its own concurrency issues with its own locks.
The issue is that the kernel and app are running asynchronously with an implicit race condition around removing file descriptors from epoll; sending a notification through the normal epoll mechanism that the kernel is done should be enough to allow both sides of the API to run asynchronously.
|
|||||||||||||