[Stackless] Why does xsdb use stackless?
aaron at reportlab.com
Wed Dec 10 16:50:39 CET 2003
Well, you can always use an event loop, but this argument reminds
me of a fortran programmer who says that recursion is
not important because you can always emulate it using
Unrolling the application at each point where you need to wait
simply turns the code inside out (just like unrolling
a set of recursions). Threading is the only
...Unless I simply make the concurrency restrictions
harsher and roll back any transaction which needs
regarding generators: I don't get it, they seem extremely
limited to me.
[I'm cc the stackless list on this for discussion, hope
you don't mind.]
-- Aaron Watters
Itamar Shtull-Trauring wrote:
>On Wed, 2003-12-10 at 06:09, Aaron Watters wrote:
>>Using tasklets to implement db concurrency control is particularly
>>elegant (and much more efficient than using threads, which is the only
>>really acceptable alternative).
>Yeah, threads are not the way to go. But an event loop is pretty much
>what the tasklets are running on top of anyway, no? Tasklets can make
>the code cleaner, but I don't think they'd make it fundamentally more
>efficient. That is, "read from channel" is essentially equivalent to
>finishing a function and then having a callback continue processing
>later. I suppose there's overhead of extra Python function calls and
>attribute lookups, solvable in some cases by generators...
>Still, it is a shame stackless' functionality never made it into Python.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless