Dan Burkert

Ah interesting. Yes, part of my change with `capnp-nonblock` introduced more aggressive writing behavior. Before when we wrote a message to a connection with an empty write queue, we would...

This is probably easiest to diagnose at the `capnp-nonblock` level, it should be possible to create a unit test there.

err well maybe not. `capnp-nonblock` doesn't have any MIO based tests, but it does have a MIO example. maybe we can recreate with that simpler example.

> It just seems wrong to me to immediately start writing to a socket that has O_NONBLOCK set (at least that's what this example indicates). What would be the expected...

OK it definitely seems like this is invalid on OS X. I changed one of the MIO [unit tests](https://github.com/danburkert/mio/commit/e6cb5776734d5c6ba1923da63440f984b25159b3) to immediately write to a socket, and it now fails on...

Alternatively, `capnp-nonblock` can swallow the not-connected error when doing the aggressive write. This is probably the most foolproof way, just need to make sure it won't swallow real errors.

just brought this up on carllerche/mio#307.

@tschottdorf I'm proposing the error only be swallowed when doing the aggressive write. At that point the connection would be registered with the event loop. If it's a real connection...

Just pushed a new version of `capnp-nonblock` that seems to have fixed the issue. Still getting random errors on OS X, but I think it's back to the original issue.

For future reference: https://github.com/danburkert/capnp-nonblock/commit/47343ce3b2cc5128a7bf2e738a1cd24b3819131d