From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,BAYES_00,
 URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2
X-Original-To: sleepy-penguin@bogomips.org
Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net
 (Postfix) with ESMTP id 6F0472042E; Mon,  7 Dec 2015 04:13:30 +0000 (UTC)
Date: Mon, 7 Dec 2015 04:13:30 +0000
From: Eric Wong <e@80x24.org>
To: Daniele Orlandi <daniele@orlandi.com>
Cc: sleepy-penguin@bogomips.org
Subject: Re: Events are still delivered after an IO object is deleted from
 epoll
Message-ID: <20151207041330.GA5074@dcvr.yhbt.net>
References: <5664FAC6.8040705@orlandi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5664FAC6.8040705@orlandi.com>
List-Id: <sleepy-penguin@bogomips.org>

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!