[Stackless] Stackless and Twisted [was: Stackless and Psyco]

Christopher Armstrong radix at twistedmatrix.com
Wed Mar 3 03:23:44 CET 2004

Christian Tismer wrote:
> Christopher Armstrong wrote:
>> Christian Tismer wrote:
> ...
>>> Is it possible to spell out what's wrong/missing in Stackless?
>>> I'd really like to support Twisted; we need to share some information.
>>> (I'm the specialist here, you are the specialist there...)
>> No no no, nothing wrong with stackless in the context of Twisted, at 
>> least as far as this problem is concerned. It's just a fundamental 
>> issue with context-switching when current, un-stacklessy code isn't 
>> expecting it. It's not a major issue, like it is with regular 
>> pre-emptive threading, but it can still be a concern in cases like I 
>> pointed out.
> But Stackless does no automatic scheduling at the moment.
> You mean the problem is that a function which knows what
> it calls usually can expect that exactly that and nothing else
> is run?
> And if some code decides to schedule(), this assumption is broke?
> So Twisted is doing something like "locking by call", in the sense
> that it is implicitly locked, since *now just this* function
> is able to run?
> This would of course mean to need more explicit locking of
> resources, if I understand this at all.

Ok, I'll try to clarify. This problem I'm talking about actually has 
nothing at all to do with Twisted. Indeed, it is when A's code calls B's 
code and A won't expect B to context switch and do other stuff, maybe 
calling A's own code again. This could cause messed up state. "locking 
by call" is accurate in some sense, but it's really how all simple, 
synchronous code works. This problem could show up when we try to 
integrate our stacklessy-B code with any mundane-A framework-code. By 
"framework-code" I mean "third-party code which calls my code".

Now, in Twisted this problem actually avoidable in many cases: Twisted 
is asynchronous, so many times A will require B to return a Deferred: 
i.e., B is asynchronous. This code will already be able to handle B 
doing weird things, because A returns to the mainloop. Returning to the 
mainloop is a declaration that A is ready and willing to service other 
requests, or whatever.

I hope that wasn't too confusing. The point is that the requirements 
placed on A are "be ready for 'context switches' and keep your state in 
order despite them". Since Deferreds force our A code to be ready for 
this, we can just wrap B (which might do stackless context-switches) 
with a Deferred, and then stacklessy-B can work with any deferredy-A, 
which is most of Twisted and Twisted-using code.

  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://www.stackless.com/pipermail/stackless/attachments/20040302/4c55125a/attachment.pgp>
-------------- next part --------------
Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list