[Stackless] unexpected tasklet & channel behaviour
ardatur at mail.ru
ardatur at mail.ru
Wed Nov 1 10:13:56 CET 2006
Wednesday, November 1, 2006, 10:35:59 AM, you wrote:
RT> The only reference to the channel is inline, and when it
RT> garbage collected...
Interesting point, I haven't thought about gc... But actually the same
result is obtained with `gc.disable()'. And anyway, if the reason were
in gc, we should have seen `1 b', `2 b', ..., `5 b' lines in the output,
RT> Because f2 holds a local reference to the channel, the
RT> tasklets on it do not get unblocked and any attempt to
RT> manually run them fails, as it should.
While receive() in f1 executes, doesn't something hold a reference
to the respective channel, too?
>> 2) looks like `t1.run()' in the case 4 runs both t1 and t2, which
>> results in a `t2.run()' failure.
RT> Yes. This is something that confused me too. Doing tasklet.run
RT> does not just run that tasklet. It runs that tasklet and then all the
RT> other scheduled tasklets after it the chain are run next, then it
RT> No real bugs here. Just unexpected ways things work :)
OK, so tasklets are `already started, but not yet' even before run(),
and this call only removes the `not yet' part, after which the
scheduler kicks in and executes all tasklets, including those which
are still in a `not yet' state. Unexpected, yeah :) .
Well, that's one half of a problem. The other half is still about the
`6 b' line. I guess I should've asked more detailed questions:
* why `6 b' but not `5 b'? These two tasklets are the same func in
different microthreads, shouldn't they be either both finished or both
* the `6 a' line is (like in case 4) output after `t1.run()', not
`t2.run()'; and the `6 b' is reported after `t2.run()'. In the case 4
the same call spawned an exception---in the case 3 the receive()
simply returns None. Isn't it an inconsistency?
Stackless mailing list
Stackless at stackless.com
More information about the Stackless