[Stackless] stackless and threads

Richard Emslie rxe at ukshells.co.uk
Fri Jul 18 23:19:48 CEST 2003



Hi Christian,

On Mon, 14 Jul 2003, Christian Tismer wrote:

[on switching tasklets with multiple threads / interpreters]

> > However, I am making the gross assumption that (a) the python interpreters
> > running in seperate threads are thread safe and (b) don't suffer from GIL.
> > Christian : can we get away with tasklet switches in seperate interpreters
> > or do we have the same problem?
>
> We have a problem with tasklets which have C state. These cannot
> be transferred. We can transfer tasklets with no C state.
> I also can make this easier and more explicit:
> It might be thinkable to make some migrate function that
> grabs a tasklet and puts it into a different thread,
> which also might belong to a different interpreter.
> But this is exactly then possible when the pickling trick works.
>

I was thinking this is a reasonable restriction.  As it stands, and
correct me if I am wrong, it is impossible to auto schdeule any tasklets
with C state.  So if a tasklet is blocked from inside some C code (recv,
send or on the list of runnables) it cannot be pickled?  However, if a
tasklet calls some C code which returns immediately, and continues with
bytecodes, there is no reason it can't be pickled or switched via frame
pushing?

Actually there is an outstanding problem with the above, If tasklet calls
some C code and then calls back into the interpreter, are they combined
into one set of frames for that tasklet?  Therefore the above is not true,
because auto scheduling could occur when back into executing bytecode?
Therefore any tasklets that call C code which calls back into intrepreter,
is deemed to C state and hence not pickable?

> > An alternative solution would be to use nonblocking IO and create our own
> > poll like functions via a tasklet and a scheduler object.  It wouldn't be
> > as efficient - but it would mean we could run the likes of networking code
> > in one thread.  A high level library such as Pyro (stackless-ified ;-))
> > could be used to farm out work to other processes if the box has more than
> > processor and migrate pickled tasklets to other processes.
>
> Why would you want to use poll at all?
> IronPort has made a very efficient solution
> using BSD kernel queues, so-called kqueues.
> And I know there are (while less efficient) ways
> to simulate this.
> Basically, the idea is to wait for an action on a large
> number of connections, and then to feed the result/request
> to as many tasklets as necessary.
>

Yes - that's exactly how to do it... thankyou :-)

I am going to have a play with epoll() for linux and maybe write some sort
asynccore equvilent - but mostly written in C.  If anyone is interested in
this I throw the code on Christian's wiki (if that's ok).


> > The second solution also allows us have very large number of connections
> > open without grinding the OS to halt with excessive amounts of threads &
> > context switching.
>
> I believe, this should be doable with at most one extra
> real thread, unless, the OS is Windows. On the latter, I
> think to remember there is an upper limit for the concurrent
> arguments in one WaitForMultipleObjects call.
>

Yes one thread to do all the comms in C and perhaps using a channel for
the queue so that we have a number of tasklets which listen on it for
connections, and then using receive() to be rewakened on receiving data.
Only problem here is timeouts, polling is great for timeouts, however, I
guess we could send an exception to that tasklet from the C code.

Many thanks Christian - sorry for asking so many questions.  Did you get
chance to look at the autoscheduling stuff I sent?

Cheers,
Richard




> ciao  - chris
> --
> Christian Tismer             :^)   <mailto:tismer at tismer.com>
> Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
> Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
> 14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
> work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>       whom do you want to sponsor today?   http://www.stackless.com/
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at www.tismer.com
> http://www.tismer.com/mailman/listinfo/stackless
>
_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless




More information about the Stackless mailing list