Chris's Wiki :: blog/programming/PureBlockingAPIsWhyBad Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/PureBlockingAPIsWhyBad?atomcommentsDWiki2017-03-04T21:04:08ZRecent comments in Chris's Wiki :: blog/programming/PureBlockingAPIsWhyBad.By Chris Siebenmann on /blog/programming/PureBlockingAPIsWhyBadtag:CSpace:blog/programming/PureBlockingAPIsWhyBad:995248b055f0f2c166613a21f5e7ddb5a849f89cChris Siebenmann<div class="wikitext"><p>Let me elaborate the 'IO as channel operations' idea, which I see I
actually phrased badly and misleadingly in my entry. In very sketchy
form:</p>
<ul><li>IO operations like reading and writing are channel operations
(basically channel receives, since they have to return status results).
This makes them intrinsically blocking if done by themselves.<p>
</li>
<li>As channel operations, you can put them in a <code>select</code> with each other
and with other channel operations, such as receiving a message from a
notification channel. As with conventional <code>select</code>, the runtime
guarantees that exactly one of these operations will happen as far as
you're concerned; you never get both a <code>read()</code> and a timer channel
notification.<p>
</li>
<li>The runtime further guarantees that IO operations in a <code>select</code> are
not even initiated until they can complete (as the winning channel
operation). The runtime does not issue a bunch of <code>read()</code>s behind
your back and then return completion information for one of them as
the channel receive; instead it <code>epoll()</code>s on everything and only
initiates one <code>read()</code> on whichever IO channel won the <code>select</code>.</li>
</ul>
<p>Not all IO operations can be handled quite this way, because some of them
are intrinsically initiated and then you get a completion notification
(one example is <code>connect()</code> on sockets). Operations that must be initiated
and then waited for give you an explicit channel, which you then receive
from or <code>select</code> as before. This exposes that there is in-flight activity
that you may need to think about if you decide to abandon things.</p>
<p>I'm not convinced that this is a good API (for a start, real <code>epoll()</code> is
often far more dynamic than <code>select</code> is, since <code>select</code> has a hard-coded
channel list). But I think it's at least a blocking IO API that avoids
the basic problem of IO cancellation.</p>
</div>2017-03-04T21:04:08ZBy Chris Siebenmann on /blog/programming/PureBlockingAPIsWhyBadtag:CSpace:blog/programming/PureBlockingAPIsWhyBad:d6010705f11b5d5e98dae930cad65b3461c0856eChris Siebenmann<div class="wikitext"><p>I see <code>async</code>/<code>await</code> as different because my understanding is that in it,
the underlying IO begins the moment the <code>async</code> operation is started. You
cannot cancel it as such, merely not wait for it to complete. In theory a
runtime could be complicated enough to use <code>select()</code> initially and then
materialize the actual <code>read()</code> only when you did an <code>await</code>, but that
seems chancy and probably against the mental model that users will expect
and that other bits of code are expecting.</p>
<p>(A more complicated runtime could start out by <code>select()</code>ing for all
<code>async</code> IO, and then if the wait was abandoned before the IO became
ready it could stop there. But that requires the runtime to know for
sure that the wait has been abandoned.)</p>
</div>2017-03-04T20:01:08ZBy Aristotle Pagaltzis on /blog/programming/PureBlockingAPIsWhyBadtag:CSpace:blog/programming/PureBlockingAPIsWhyBad:5c05e60b9bbdac02041db5ab132de8a0df7d3cbeAristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><blockquote><p>The basic idea is to create a CSP like environment where […] the thread performing the IO simply uses a multi-select, where one channel is the IO operation and another is the 'abort the operation' channel.</p>
</blockquote>
<p>Isn’t the <code>async</code>/<code>await</code> model every language and its dog seems to be adopting these days just that?</p>
</div>2017-03-04T12:35:14ZBy Phillip on /blog/programming/PureBlockingAPIsWhyBadtag:CSpace:blog/programming/PureBlockingAPIsWhyBad:72e0886975e198006fcc3430ca9b053993369194Phillip<div class="wikitext"><p>Did you have a chance to look at Python 3.6+'s coroutines and asyncio yet? boost::asio is similar, and both copied the model from C#, I believe: They provide a API that looks as if you'd do (cancelable) blocking I/O, but are actually single-threaded and based on select/poll/epoll.</p>
</div>2017-03-04T12:10:46Z