Messages in this thread | | | Date | Tue, 19 Jun 2012 20:17:11 +0200 | From | Christof Meerwald <> | Subject | Re: [PATCH] epoll: Improved support for multi-threaded clients |
| |
Hi Paton,
On Mon, Jun 18, 2012 at 04:24:35PM -0700, Paton J. Lewis wrote: > We believe that EPOLLONESHOT is required in order to make any > sensible use of calling epoll_wait on a single epoll set > concurrently in multiple threads.
I guess we have to disagree here - though it might be more difficult.
> >On Mon, 11 Jun 2012 15:34:49 -0700, Paton Lewis wrote: > >> This patch introduces the new epoll_ctl command EPOLL_CTL_DISABLE, which > >> disables the associated epoll item and returns -EBUSY if the > >epoll item is not > >> currently in the epoll ready queue. This allows multiple threads to use a > >> mutex to determine when it is safe to delete an epoll item and > >its associated > >> resources. This allows epoll items to be deleted and closed efficiently and > >> without error.
Maybe I am missing something here (as I am not really familiar with the kernel internals), but I don't really understand the logic behind your patch. Isn't the "expected" case that the item is not on the ready list and no I/O is being processed for that item?
So I think instead of checking for the item being on the ready list, checking for the event mask would make more sense for me, e.g.
if (!(epi->event.events & ~EP_PRIVATE_BITS))
But, taking one step back - wouldn't an alternative approach be to add some mechanism to allow a thread to post a user-event for an fd? So in delete_epoll_item you would post a user event (e.g. EPOLLUSER) for the fd which you can then handle in your epoll_wait processing thread - with no additional synchronisation necessary.
However, this would still require EPOLLONESHOT to be useful for memory management.
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
| |