[Async-sig] APIs for backpressure (was: Re: Some thoughts on asynchronous API design in a post-async/await world)

[Cory Benfield]

> On 8 Nov 2016, at 21:07, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> 
> 
>> On Nov 8, 2016, at 2:17 AM, Cory Benfield <cory at lukasa.co.uk <mailto:cory at lukasa.co.uk>> wrote:
>> 
>> Tubes is unquestionably a better API for this, but suffers from a lack of accessibility.
> 
> What is "accessibility" in this context?

“accessibility” in this context is essentially the collection of things that make it easy for users to a) identify a need for tubes, b) work out how to plug tubes into their application, and c) have a sensible evolution to handle evolving backpressure needs into tubes.

Mostly this is a documentation thing, but there’s also a chicken-and-egg problem here, specifically: tubes provides a high-level API for flow control but requires that pre-existing code use a low-level one. How do we get from there to somewhere we can actually tell people “yeah, go use tubes”?

On top of that we have: how do we justify using tubes when so much of for example Twisted’s codebase does not implement IPushProducer/IConsumer? How do people migrate a pre-existing codebase to something like tubes? How do people extend tubes to do something other than *propagate* backpressure (e.g. to implement a fast-fail path to error out rather than stop reading from a socket). All of these questions *have* answers, but those answers aren’t easily accessible.

Part of this is an ongoing cultural problem which is that people who build small or non-distributed applications often don’t have to think about backpressure, so there’s another problem that also needs addressing: it needs to be so easy for people to extend their async producers and consumers of data to propagate and respond to backpressure appropriately that there’s no good reason *not* to do it.

All of this complex mess of things is what I mean by “accessibility”. It needs to be easier to do the right thing than the wrong thing.

Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161109/83df4092/attachment.html>