Microthreads without Stackless?

[Michael Sparks]

Patrick Maupin wrote:

> Michael Sparks wrote:
 
> IMO, this example does not demonstrate a reasonable use-case for
> coroutines.

The implied use case is this:
   1 An arbitrary piece of library code that can accept a function (or
     object with attached method) for processing data.
   2 This arbitrary piece of code gets called by a coroutine, and is passed
     a process function that has somewhere buried inside it's call chain
     something that causes a coroutine switch.

In terms of code, 1 isn't such an odd or unusual a concept. You would
normally expect library code to have well defined known semantics. However
by placing that commonly used code in the call chain you break it's
semantics.

Unless you think that no coroutine is ever going to use library code of some
kind (either in-house or some shared library, or even just stuff in the
standard python distro), then it is indicative of the sort of thing that
could happily sit half way through a call stack in a stackful coroutine.

> Two good use cases for coroutines are:
> [ couple of examples ]

Note: I did say that in some circumstances they do make life simpler.
However by adding them in at all, you _risk_ making reasoning about the
entire system more complex, not simpler, depending on the implementation.
It's *not* just sufficient to say that it's stackful.

> (As an aside, IMO your example also fails to demonstrate good
> try/except/finally hygiene, which would be a completely peripheral
> argument, except that you're arguing that Python should always do the
> "right thing" with this code, and you're not even using what I would
> consider to be the right constructs for that.)

Consider that normally you'd use try: finally: and that simple generators
don't allow the use of finally due to the fact that the finally clause is
not guaranteed to get any CPU time. Whether it's reasonable to assume that
hypothetical coroutine code would have similar restrictions to generator
code is an exercise for the reader...

That was the reason for the odd try/except/finally "hygiene". The reason for
the bare except was to point out that it would catch any and all errors as
you would normally with finally. You state that you think what I was doing
wasn't good hygiene - however it's one of the few options you have if you
use generators at present. I was aiming for consistency with that, not
sanity :)

>> I would argue that you cannot, unless you start placing restrictions on
>> the coroutines in a way you (and others) haven't detailed. (Such as
>> ensuring that when you throw something like exceptions.SystemExit that it
>> propogates through all the co-routines and hits all the bare except
>> clauses and isn't stopped by any single one of them.)
> 
> I guess this is the old "you'll put your eye out with that thing"
> argument. 

I wouldn't say that's ever a reason for not putting something in a language.
You'd never allow anyone to delete files on the disk otherwise... I was
merely pointing out that you stated coroutines simplify reasoning, whereas
in practice it can _break_ the _normal_ reasoning you have for the bulk of
your code.

>...  I submit that coroutines would be a satisfactory solution 

You seem to be arguing from the point of view that seems to think I'm
against the idea of coroutines entering python, whereas all I was doing was
pointing out that coroutines potentially break the reasoning for very
common code, depending on how they are added. (if say generators were ever
to be extended to be more stackful than they are)

I use generators at present for a lot of the tasks that coroutines would
naturally sit into. Indeed I use them because they fulfill a lot of what
coroutines would provide, and it was one of our reasons for choosing
python in the first place. Even so one of the first questions I asked
regarding them was "can they be wrapped/nested" (ie made stackful).

It's not, perhaps, quite as nice as "full" coroutines, but then it's
nicer than the equivalent in many other languages.

Regards,


Michael.