[Stackless] [threading] Stackless based replacement
senn at maya.com
Fri Sep 26 16:54:16 CEST 2008
On Sep 26, 2008, at 9:50 AM, David Naylor wrote:
> My atomic is based on .set_atomic, and there should not be any
> passing of control. I compensated for it [the apparent bug?] by
> forcing a
> reschedule until the correct tasklet came about...
> Unfortunately my code that generates this problem is FreeBSD based
> and will
> only work with FreeBSD Ports (If you have I will gladly send you the
Doesn't help me. :-(
>>> 2) Will stackless switch to another tasklet when entering blocking
>>> (like IO), I know threads do this...
>> No it won't. In fact, it fundamentally *can't* (since it "runs" in
>> only one thread).
> Surely there is a way around this? Some kind of pooling select? If
> there is
Well... not, not tractably. Realize the tasklets are very bound to
they are running within. If that thread is busy in I/O... then it's
to be able to switch to another tasklet. ....
> no work around then I cannot see too much practical use for my
> thread library
> [except having to avoid learning tasklets for someone who is
> familiar with
> As I understand it, due to the GIL the only real practical use for
> threads is if one has blocking function calls (IO-type, etc)
(or extensions running w/o the GIL)
This broader issue has been discussed several times on this list,
if you are interested you might want to go through the archives.
> [Has the GIL restriction been fixed in 3k?
Heh! No. And it probably won't be:
>>> Did you mean "threads" or "tasklets"?
>> If you meant "threads" the answer is complicated... if you meant
>> then see the parameter to stackless.run.
> I asked because I remember somewhere that python does a 'switch'
> every X
> lines... I just wanted to pass the same number to run().
There is some loop counter in eval (that I believe defaults to 100) that
affects the granularity of thread switching (by giving up the GIL every
N iterations) -- this does not really map to "lines" however.
If you actually wanted stackless to autoschedule this fast I believe
since the number passed to run is "layered" on the eval loop counter.
More information about the Stackless