Cc: python-id...@python.org
Subject: Re: [Python-ideas] yield from multiple iterables (was Re: The async API of the future: yield-from)

Steve, I realize that continued point-by-point rebuttals probably are getting pointless. Maybe your enthusiasm and energy would be better spent trying to propose and implement (a prototype) of an API in the style that you prefer? Maybe we can battle it out in code more easily...

--
--Guido van Rossum (python.org/~guido)

_______________________________________________
Python-ideas mailing list
Python-id...@python.org
http://mail.python.org/mailman/listinfo/python-ideas

> Apart from the network server and client examples that have already been discussed, any particular problems I should be looking at solving with this? (Anyone?) I don't want to only come up with 'good' examples.

> I think there's an assumption behind this whole async tasks discussion that the tasks
> being scheduled are I/O bound. We're trying to overlap CPU activity with I/O, and
> different I/O activities with each other.
> We're *not* trying to achieve concurrency of CPU-bound tasks -- the GIL prevents that
> anyway for pure Python code.

> I gather that Windows provides a way of making an async I/O request and specifying a
> callback for that request. If that's the case, do we need to bother with an IOCP at all?
> Just have the callback wake up the associated task directly.

>> (Aside: please don't use 'continuation' for 'task'. The use of this
>> term in Scheme has forever tainted the word for me.)

> It has a broader meaning than the one in Scheme; essentially
> it's a synonym for "callback".

> I guess that was just Steve showing off. :-)

>>> I agree [continuation] shouldn't be used as a synonym for "task", though.
>>> In any of its forms, a continuation isn't an entire task, it's
>>> something that you call to cause the resumption of a task
>>> from a particular suspension point.

>> I guess that was just Steve showing off. :-)

> Not intentionally - the team here that did async/await in C# talks a lot about "continuation-passing style", which is where I picked the term up from. I don't use it as a synonym for "task" - it's always meant the "bit that runs after we come back from the yield" (hmm... I think that definition needs some work...).

>> The reason we can't ignore IOCP is that it is apparently the *only*
>> way to do async I/O in a scalable way. The only other polling
>> primitive available is select() which does not scale.

> There seems to be an alternative to polling, though. There are
> functions called ReadFileEx and WriteFileEx that allow you to
> pass in a routine to be called when the operation completes:

> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365468%28v=...
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365748%28v=...

> Is there some reason that this doesn't scale either?

> On Mon, Oct 22, 2012 at 4:04 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> > Guido van Rossum wrote:

> >> The reason we can't ignore IOCP is that it is apparently the *only*
> >> way to do async I/O in a scalable way. The only other polling
> >> primitive available is select() which does not scale.

> > There seems to be an alternative to polling, though. There are
> > functions called ReadFileEx and WriteFileEx that allow you to
> > pass in a routine to be called when the operation completes:

> > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365468%28v=...
> > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365748%28v=...

> > Is there some reason that this doesn't scale either?

> I don't know, we've reached territory I don't know at all. Are there
> also similar calls for Accept() and Connect() on sockets? Those seem
> the other major blocking primitives that are frequently used.

> FWIW, here is where I read about IOCP being the only scalable way on
> Windows: http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libev...

>>It has a broader meaning than the one in Scheme; essentially
>>it's a synonym for "callback".

> (Off-topic:) But does that meaning apply to Scheme? If so, I wish
> someone would have told me 15 years ago...

>> On Mon, Oct 22, 2012 at 3:33 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
>> wrote:

>>  It has a broader meaning than the one in Scheme; essentially
>>> it's a synonym for "callback".

>> (Off-topic:) But does that meaning apply to Scheme? If so, I wish
>> someone would have told me 15 years ago...

> It does, in the sense that a continuation appears to the
> Scheme programmer as a callable object.

> The connection goes deeper as well. There's a style of
> programming called "continuation-passing style", in which
> nothing ever returns -- every function is passed another
> function to be called with its result. In a language such
> as Scheme that supports tail calls, you can use this style
> extensively without fear of overflowing the call stack.

> You're using this style whenever you chain callbacks
> together using Futures or Deferreds. The callbacks don't
> return values; instead, each callback arranges for another
> callback to be called, passing it the result.

> This is also the way monadic I/O works in Haskell. None
> of the I/O functions ever return, they just call another
> function and pass it the result. A combination of currying
> and syntactic sugar is used to hide the fact that you're
> passing callbacks -- aka continuations -- around all
> over the place.

> Now, it turns out that you can define all the semantics
> of Scheme, including its continuations, by writing a Scheme
> interpreter in Scheme that doesn't itself use Scheme
> continuations. You do it by writing the whole interpereter
> in continuation-passing style, and it becomes clear that
> at that level, the "continuations" are just ordinary
> functions, relying on lexical scoping to capture all of the
> necessary state.

>  I guess that was just Steve showing off. :-)

> Not really -- to someone with a Scheme or FP background,
> it's near-impossible to look at something like a chain
> of Deferred callbacks without the word "continuation"
> springing to mind. I agree that it's not helpful to
> anyone without such a background, however.

> --
> Greg

> ______________________________**_________________
> Python-ideas mailing list
> Python-id...@python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>

> > The reason we can't ignore IOCP is that it is apparently the *only*
> > way to do async I/O in a scalable way. The only other polling
> > primitive available is select() which does not scale.

> There seems to be an alternative to polling, though. There are functions called
> ReadFileEx and WriteFileEx that allow you to pass in a routine to be called when
> the operation completes:

> http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa365468%28v=vs.85%29.aspx
> http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa365748%28v=vs.85%29.aspx

> Is there some reason that this doesn't scale either?

> Personally, I'm interested in designing a system, including an event
> loop, where you can rely on the properties of cooperative scheduling
> to avoid ever touching (OS) threading locks. I think such a system
> should be "pure" and all interaction with threads should be mediated
> by the event loop. (It's okay if this means that the implementation of
> the event loop must at some point acquire a threading lock.) The
> Futures used by the tasks to coordinate amongst themselves should not
> require locking -- they should themselves be able to rely on the
> guarantees of the event loop not to invoke multiple callbacks in
> parallel.

> IIUC you can do this on Windows with IOCP too, simply by only having a
> single thread reading events.

>> (*I'm inclined to define this [the Future interface] as 'result()', 'done()',
>> 'add_done_callback()', 'exception()', 'set_result()' and 'set_exception()'
>> functions. Maybe more, but I think that's sufficient. The current
>> '_waiters' list is an optimisation for add_done_callback(),  and doesn't
>> need to be part of the interface.)
> Agreed. I don't see much use for the cancellation stuff and all the
> extra complexity that adds to the interface.

>> I did a basic timing test using a simple recursive function and a
>> recursive PEP-380 coroutine computing the same value (see attachment).
>> The coroutine version is a little over twice as slow as the function
>> version. I find that acceptable. This went 20 deep, making 2 recursive
>> calls at each level (except at the deepest level).

> Note that the co-routine code (copied below) does not involve a
> scheduler that unwraps futures; there is no scheduler, and nothing
> runs concurrently.

>     def coroutine(n):
>         if n <= 0:
>             return 1
>         l = yield from coroutine(n-1)
>         r = yield from coroutine(n-1)
>         return l + 1 + r

> I like the above code; my concern was that yield might get co-opted
> for use with scheduler loops, which would have to track the parent
> task explicitly, and prevent it from being rescheduled too early.

> On Oct 22, 2012, at 4:59 PM, Guido van Rossum <gu...@python.org> wrote:

>> On Sun, Oct 21, 2012 at 10:30 PM, Steve Dower <Steve.Do...@microsoft.com> wrote:
>> [Stuff about Futures and threads]

>> Personally, I'm interested in designing a system, including an event
>> loop, where you can rely on the properties of cooperative scheduling
>> to avoid ever touching (OS) threading locks. I think such a system
>> should be "pure" and all interaction with threads should be mediated
>> by the event loop. (It's okay if this means that the implementation of
>> the event loop must at some point acquire a threading lock.) The
>> Futures used by the tasks to coordinate amongst themselves should not
>> require locking -- they should themselves be able to rely on the
>> guarantees of the event loop not to invoke multiple callbacks in
>> parallel.

>> IIUC you can do this on Windows with IOCP too, simply by only having a
>> single thread reading events.

> Maybe it is worth to have a look on libuv and the way it mixes threads and  and event loop [1]. Libuv is one of the good event loop around able to use IOCP and other events systems on other arch (kqueue, …) and I was thinking when reading all the exchange around that it would perfectly fit in our cases. Or at least something like it:

> - It provides a common api for IO watchers: read, write, writelines, readable, writeable that can probably be extend over remote systems
> - Have a job queue system for threds that is working mostly like the Futures but using the event loop

> In any case there is a pyuv binding [2] if some want to test. Even a twisted reactor [3]

> I myself toying with the idea of porting the Go concurrency model to Python [4] using greenlets and pyuv. Both the scheduler and the way IOs are handled:

> - In Go all coroutines are independent from each others and can only communicate via channel. Which has the advantage to allows them to run on different threads when one is blocking. In normal case they are mostly working like grrenlets on a single thread and are simply scheduled in a round-robin way. (mostly like in stackless). On the difference that goroutines can be executed in parallel. When one is blocking another thread will be created to handle other goroutines in the runnable queue.

> - For I/Os it exists a common api to all Connections and Listeners (Conn & Listen classes) that generally ask on a poll server. This poll server has for only task to register FDs and wake up the groutines that wait on read or fd events. This this poll server is running in a blocking loop it is automatically let by the scheduler in a thread. This pol server could be likely be replaced by an event loop if someone want.

> In my opinion the Go concurrency & memory model [5] could perfectly fit in the Python world and I'm surprised none already spoke about it.

> In flower greenlets could probably be replaced by generators but i like the API proposed by any coroutine pattern. I wonder if continulets [6] couldn't be ported in cpython to handle that…

> - benoît

> [1] http://nikhilm.github.com/uvbook/threads.html & http://github.com/joyent/libuv
> [2] https://github.com/saghul/pyuv
> [3] https://github.com/saghul/twisted-pyuv
> [4] https://github.com/benoitc/flower
> [5] http://golang.org/ref/mem
> [6] http://doc.pypy.org/en/latest/stackless.html#continulets

>>> It has synchronisation which is _aware_ of threads, but it never creates,
>>> requires or uses them. It simply ensures thread-safe reentrancy, which
>>> will be required for any general solution unless it is completely banned
>>> from interacting across CPU threads.

>> I don't see it that way. Any time you acquire a lock, you may be
>> blocked for a long time. In a typical event loop that's an absolute
>> no-no. Typically, to wait for another thread, you give the other
>> thread a callback that adds a new event for *this* thread.

> That (with or without rescheduling this thread to actually process the
> event) is a perfectly reasonable solution, but I'm not sure how
> obvious it is.  People willing to deal with the conventions and
> contortions of twisted are likely to just use twisted.

> wait_for_any may well be launching different strategies to solve the
> same problem, and intending to ignore all but the fastest.  It makes
> sense to go ahead and cancel the slower strategies.  (That said, I
> agree that the API shouldn't guarantee that other tasks are actually
> cancelled, let alone that they are cancelled before side effects
> occur.)

> --Guido

> On Tue, Oct 23, 2012 at 12:19 AM, Benoit Chesneau <beno...@gunicorn.org>
> wrote:

> > On Oct 22, 2012, at 4:59 PM, Guido van Rossum <gu...@python.org> wrote:

> >> On Sun, Oct 21, 2012 at 10:30 PM, Steve Dower <
> Steve.Do...@microsoft.com> wrote:
> >> [Stuff about Futures and threads]

> >> Personally, I'm interested in designing a system, including an event
> >> loop, where you can rely on the properties of cooperative scheduling
> >> to avoid ever touching (OS) threading locks. I think such a system
> >> should be "pure" and all interaction with threads should be mediated
> >> by the event loop. (It's okay if this means that the implementation of
> >> the event loop must at some point acquire a threading lock.) The
> >> Futures used by the tasks to coordinate amongst themselves should not
> >> require locking -- they should themselves be able to rely on the
> >> guarantees of the event loop not to invoke multiple callbacks in
> >> parallel.

> >> IIUC you can do this on Windows with IOCP too, simply by only having a
> >> single thread reading events.

> > Maybe it is worth to have a look on libuv and the way it mixes threads
> and  and event loop [1]. Libuv is one of the good event loop around able to
> use IOCP and other events systems on other arch (kqueue, …) and I was
> thinking when reading all the exchange around that it would perfectly fit
> in our cases. Or at least something like it:

> > - It provides a common api for IO watchers: read, write, writelines,
> readable, writeable that can probably be extend over remote systems
> > - Have a job queue system for threds that is working mostly like the
> Futures but using the event loop

> > In any case there is a pyuv binding [2] if some want to test. Even a
> twisted reactor [3]

> > I myself toying with the idea of porting the Go concurrency model to
> Python [4] using greenlets and pyuv. Both the scheduler and the way IOs are
> handled:

> > - In Go all coroutines are independent from each others and can only
> communicate via channel. Which has the advantage to allows them to run on
> different threads when one is blocking. In normal case they are mostly
> working like grrenlets on a single thread and are simply scheduled in a
> round-robin way. (mostly like in stackless). On the difference that
> goroutines can be executed in parallel. When one is blocking another thread
> will be created to handle other goroutines in the runnable queue.

> > - For I/Os it exists a common api to all Connections and Listeners (Conn
> & Listen classes) that generally ask on a poll server. This poll server has
> for only task to register FDs and wake up the groutines that wait on read
> or fd events. This this poll server is running in a blocking loop it is
> automatically let by the scheduler in a thread. This pol server could be
> likely be replaced by an event loop if someone want.

> > In my opinion the Go concurrency & memory model [5] could perfectly fit
> in the Python world and I'm surprised none already spoke about it.

> > In flower greenlets could probably be replaced by generators but i like
> the API proposed by any coroutine pattern. I wonder if continulets [6]
> couldn't be ported in cpython to handle that…

> > - benoît

> > [1] http://nikhilm.github.com/uvbook/threads.html &
> http://github.com/joyent/libuv
> > [2] https://github.com/saghul/pyuv
> > [3] https://github.com/saghul/twisted-pyuv
> > [4] https://github.com/benoitc/flower
> > [5] http://golang.org/ref/mem
> > [6] http://doc.pypy.org/en/latest/stackless.html#continulets

> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-id...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas