[Python-ideas] Async API: some code to review

[Steve Dower]

Richard Oudkerk wrote:
> On 28/10/2012 11:52pm, Guido van Rossum wrote:
>> I'm most interested in feedback on the design of polling.py and
>> scheduling.py, and to a lesser extent on the design of sockets.py;
>> main.py is just an example of how this style works out in practice.
>
> What happens if two tasks try to do a read op (or two tasks try to do a
> write op) on the same file descriptor?  It looks like the second one to
> do scheduling.block_r(fd) will cause the first task to be forgotten,
> causing the first task to block forever.

I know I haven't posted my own code yet (coming very soon), but I'd like to put out there that I don't think this is an important sort of question at this time. We both have sample schedulers that work well enough to demonstrate the API, but aren't meant to be production ready.

IMO, the important questions are:

 - how easy/difficult/flexible/restrictive is it to write a new scheduler as a core Python developer?
 - how easy/difficult/flexible/restrictive is it to write a new scheduler as an end user?
 - how easy/difficult/flexible/restrictive is it to write async operations as a core Python developer?
 - how easy/difficult/flexible/restrictive is it to write async operations as an end user?
 - how straightforward is it to consume async operations?
 - how easy is it to write async code that is correct?

Admittedly, I am writing this preemptively knowing that there are a lot of distractions like this in my code (some people are going to be horrified at what I did with file IO :-) Don't worry, it's only for trying the API). Once we know what interface we'll be coding against we can worry about getting the implementation perfect. Also, I imagine we'll find some more volunteers for coding (hopefully people who have done non-blocking stuff in C or similar before) who are currently avoiding the higher-level ideas discussion.

Cheers,
Steve