On Sep 26, 2008, at 9:50 AM, David Naylor wrote:
My atomic is based on .set_atomic, and there should not be any
explicit
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
code).
Doesn't help me. :-(
2) Will stackless switch to another tasklet when entering blocking
routines
(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
the thread
they are running within. If that thread is busy in I/O... then it's
not going
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
threads].
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)
Indeed.
(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:
http://www.artima.com/weblogs/viewpost.jsp?thread=214235
Did you mean "threads" or "tasklets"?
Threads
If you meant "threads" the answer is complicated... if you meant
"tasklets"
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
you would:
stackless.run(1)
since the number passed to run is "layered" on the eval loop counter.
-Jas
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
