[Stackless] Stackless based replacement

Larry Dickson ldickson at cuttedge.com
Fri Oct 10 00:54:33 CEST 2008

On 10/9/08, Arnar Birgisson <arnarbi at gmail.com> wrote:
> Hi Larry,
> On Thu, Oct 9, 2008 at 22:06, Larry Dickson <ldickson at cuttedge.com> wrote:
> > Did my message (20081006) get through with the attached notes? I haven't
> > heard any responses, and I'm wondering if the attachments (just short
> text
> > things) somehow gummed things up.
> Yes, they went through :)
> I read your notes quickly, I didn't have any questions or comments.
> I'm afraid I don't totally understand where this fits in and what
> functionality it intends to replace.
> cheers,
> Arnar

It was in response to the problem you and David identified last month,
namely ---

On Fri, Sep 26 17:09:54 CEST 2008, Arnar Birgisson <arnarbi at gmail.com>
> Hey there,
> On Fri, Sep 26, 2008 at 15:50, David Naylor <dragonsa at
highveldmail.co.za> wrote:
> >> > 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
> > no work around then I cannot see too much practical use for my thread
> > [except having to avoid learning tasklets for someone who is familiar
> > 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)
> The solution would be asynchronous I/O. There have been discussions
> here occasionally about something generic, like wrapping libevent or
> similar in an interface that "looks" synchronous but in the background
> does async I/O and uses channels to make it look synchronous. I figure
> such a thing would be an excellent component of your thread library.
> > [Has the GIL restriction been fixed in 3k?  As far as I know Jython does
> > have this limitation...]
> The GIL has not been removed in Py 3.0, nor will it be removed any
> time soon. Jython does not have such a thing.

This design solves all these problems, using only C/Unix select (which you
pointed out is already used to do time.sleep) in the virtual machine; and
it runs in only one thread. There is no need to remove the GIL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20081009/687c6f1b/attachment.htm>

More information about the Stackless mailing list