Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Mail exchange with Aram Hăvărneanu on emulating edge-triggered events on event ports -- including a brilliant rant by Aram on why edge-triggered events are, in fact, a terrible idea. ;)
MIME-Version: 1.0
Received: by with HTTP; Sat, 21 Dec 2013 00:11:05 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 21 Dec 2013 00:11:05 -0800
X-Google-Sender-Auth: 1-P9HY9dQxa-Mr_9AY_InMAQXGE
Message-ID: <>
Subject: Re: select and port problems on solaris port
From: Bryan Cantrill <>
To: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= <>
Cc: Dave Cheney <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hey Aram,
Thanks (as always) for your thoughts and guidance. I thought about
this this week, and it seems that one major advantage we have is that
we are actually interposing on all system calls -- we know when the
runtime gets EAGAIN/EWOULDBLOCK/EINPROGRESS from a system call and can
use that to then (and only then) associate the event with the port.
This allows us to effectively replicate edge-triggered events on top
of level-triggered ones. While it still needs some polish (e.g., to
dynamically size the PortPollDesc array), here's a patch that both (1)
passes all tests and (2) doesn't spin on Dave's test:
Still needs some polish (e.g., I need to update the Perl script that
generates zsyscall_solaris_amd64.go), but I think that this route
seems promising. What do you think?
- Bryan
On Mon, Dec 16, 2013 at 7:32 AM, Aram H=C4=83v=C4=83rneanu <> wr=
> Oh, how I hate all this stuff in the name of performance.
> Edge-triggering is a hack done by people obsessed with reducing
> syscall count. Level triggering is so simple to understand and use.
> You block for something, and once you get it you can do whatever you
> want with it. You can process it synchronously, and then you don't
> have to do anything special, or you can process it asynchronously and
> then the only thing you have to do, the only thing, is to remember to
> add the fd back to the list of interesting fd's once you are done.
> This requirement is trivial, and in fact the explicitness of it is
> quite useful in understanding the code. You can read one byte, a
> hundred. Doesn't matter; you can do whatever you want.
> With edge-triggered events it's not like this. At first they seem
> useful because you don't have to remember to add fd's back, but that'a
> a trivial requirement. The downsides are that it's spectacularly easy
> to deadlock, you have to process it asynchronously, and you have to
> process every single byte out of it even if the semantics of the
> application doesn't require it. The kernel does the bookkeeping for
> us, but the kernel doesn't know what we want from it, so the
> programmer has to adapt to a stricter and harder to use programming
> model.
> But we're optimised, so making programming harder is okay.
> I guess what we have to do is find a way to tell the poller every time
> when we are actually interested in a fd. Now we tell it once we create
> a socket, but we need to tell it after we process any kind of I/O.
> Then we can postpone shoehorning back fd's after we get events until
> we actually care about more events. Unfortunately, this seems very
> hard.
> A hack would be to somehow consume the connection-ready event in a
> safe manner. I think if we solve this, the problem goes away (maybe we
> need to do something about errors too). This would be very easy if the
> poller would simple offer hints to the scheduler. Of course, in the
> name of performance, the poller doesn't simply offer hints, it's vital
> to the scheduler function.
> I think the easiest way to implement that hack is to special-case
> WaitWrite for Connect (or rather, not use WaitWrite, but WaitConnect
> in Connect). On non-Solaris systems WaitConnect can simply be
> WaitWrite. On Solaris won't (eventually) call runtime=C2=B7netpoll, but i=
> will block in port_get.
> --
> Aram H=C4=83v=C4=83rneanu
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment