<html>
<head>
</head>
<body>
<br>
Well, you can always use an event loop, but this argument reminds<br>
me of a fortran programmer who says that recursion is<br>
not important because you can always emulate it using <br>
a stack.<br>
<br>
Unrolling the application at each point where you need to wait<br>
simply turns the code inside out (just like unrolling<br>
a set of recursions). &nbsp;Threading is the only<br>
acceptable alternative...<br>
<br>
...Unless I simply make the concurrency restrictions<br>
harsher and roll back any transaction which needs<br>
to wait<br>
<br>
regarding generators: I don't get it, they seem extremely<br>
limited to me.<br>
<br>
[I'm cc the stackless list on this for discussion, hope<br>
you don't mind.]<br>
<br>
&nbsp; &nbsp; -- Aaron Watters<br>
<br>
Itamar Shtull-Trauring wrote:<br>
<blockquote type="cite" cite="mid:1071070007.25511.20.camel@sheriffpony">
  <pre wrap="">On Wed, 2003-12-10 at 06:09, Aaron Watters wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">Using tasklets to implement db concurrency control is particularly<br>elegant (and much more efficient than using threads, which is the only<br>really acceptable alternative).<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Yeah, threads are not the way to go. But an event loop is pretty much<br>what the tasklets are running on top of anyway, no? Tasklets can make<br>the code cleaner, but I don't think they'd make it fundamentally more<br>efficient. That is, "read from channel" is essentially equivalent to<br>finishing a function and then having a callback continue processing<br>later. I suppose there's overhead of extra Python function calls and<br>attribute lookups, solvable in some cases by generators...<br><br>Still, it is a shame stackless' functionality never made it into Python.<br><br></pre>
    </blockquote>
    <br>
    </body>
    </html>