[Stackless] added tasklet.throw

Richard Tew richard.m.tew at gmail.com
Fri Apr 5 22:56:40 CEST 2013


On Sat, Apr 6, 2013 at 5:13 AM, Kristján Valur Jónsson <
kristjan at ccpgames.com> wrote:

>  Ok, I have committed a change to the 2.7 branch (didn’t want to do the
> full merging yet, until we stabilize):****
>
> Here’s the comment:****
>
> ** **
>
> modifying edge case semantics of tasklet.throw()****
>
> 1) sending to a new tasklet works like a running tasklet.  It is scheduled,
> ****
>
> gets an unhandled exception, and things proceed as per usual in that case.
> ****
>
> 2) Sending to a dead tasklet causes a RuntimeError, unless one is sending*
> ***
>
> a TaskletExit, in which case it is just ignored.****
>
> ** **
>
> This is now pretty much the same as tasklet.raise_exception().****
>
> The thing is though, that tasklet.raise_exception() and kill() behave in a
> strange way when the target is already dead.  The dead tasklet is actually
> scheduled and the scheduling mechanism is put in motion, even though its
> “frame” is null.  It is by pure chance that things don’t break.  So, the
> case is handled like a regular uncaught exception.  But this is strange,
> since a tasklet can by definition have only one such.****
>
> Another reason I couldn’t emulate that behaviour with tasklet.throw(), is
> because it is not possible, or nice, to do so with non-immediate effect.
> we shouldn’t have a dead tasklet in the runnable queue.****
>
> Hence the change.  If the tasklet is dead, then senditng it an exception
> is clearly an error, much as trying to rebind a dead tasklet is.  Except
> for the kill, which I think ought to be a harmless special case to allow.
> ****
>
> What do you think?
>

I think I'm confused :-)


> Btw, ****
>
> This does not preclude thinking more about how to deal with unhandled
> exceptions.  The current built-in behaviour is to invoke them on the mani
> tasklet.  But here is an idea:  How about defining a class method on the
> tasklet class, default_handler(exc, val, tb), which does this?  Then,
> frameworks and others can redefine this in a subclass.****
>
> The benefit of doing this, rather than having people wrap their main
> functions in try:except, is that this will work even when the tasklet
> hasn’t started yet, when the tasklet is fresh in the runnable queue.
>
Is there a need for multiple versions of this in the same Python runtime?
 I'm not convinced, and would prefer that we kept it as simple as possible.
 To me, it seems a better fit to do a more standard global
"stackless.set_exception_handler".  But I'd prefer we don't take this
approach at all.

When I think about this and recall different frameworks I've written and
the things which got in the way, I'd prefer we made it more generic and
flexible.  Why just have an exception handler?  I think it should be a
globally applied callable wrapper for tasklets.  But rather than manually
needing to subclass a tasklet, have it applied automatically.

e.g.

def tasklet_bootstrap(f, *args, **kwargs):
    try:
        ret = f(*args, **kwargs)
    except:
        # handle

stackless.set_callable_wrapper(tasklet_bootstrap)

Cheers,
Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20130406/886f80f7/attachment.html>


More information about the Stackless mailing list