Events are still delivered after an IO object is deleted from epoll

Events are still delivered after an IO object is deleted from epoll

[Daniele Orlandi]

Hello,

I have a classic event loop like this:

      loop do
        @actor_epoll.wait do |events, io|
          receive(events, io)
        end
      end

In #receive, sometimes I close and remove an "io" object from the epoll
via #del (e.g. in a timerfd I close ad remove a socket)

However it appears that if there are queued events the block may still
be called afterwise.

Not a big deal, easily workaround-able, but you may want to give a look
at it.

Bye,

-- 
  Daniele Orlandi

Re: Events are still delivered after an IO object is deleted from epoll

[Eric Wong]

Daniele Orlandi <daniele@orlandi.com> wrote:
> In #receive, sometimes I close and remove an "io" object from the epoll
> via #del (e.g. in a timerfd I close ad remove a socket)
> 
> However it appears that if there are queued events the block may still
> be called afterwise.
> 
> Not a big deal, easily workaround-able, but you may want to give a look
> at it.

That's because the default maxevents for wait; so the underlying
epoll_wait syscall is still retrieving 64 events at once into the Ruby
process.

Try passing 1 as the maxevents argument:

        @actor_epoll.wait(1) do |events, io|
          receive(events, io)
        end

Retrieving more events into the kernel at once improves throughput
performance and benefits typical single-threaded event loops.

However, my typical usage is actually maxevents=1; but I'm a weirdo who
abuses epoll as a thread queue :)

Anyways, I've been thinking about revamping the API a bit;
so maybe this could return an array instead.

Thanks for the feedback!