[Stackless] [threading] Stackless based replacement

[Jeff Senn]

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