[Stackless] Stackless based replacement

Arnar Birgisson arnarbi at gmail.com
Fri Oct 10 01:34:18 CEST 2008

Hi Larry,

On Fri, Oct 10, 2008 at 00:54, Larry Dickson <ldickson at cuttedge.com> wrote:
> On Fri, Sep 26 17:09:54 CEST 2008, Arnar Birgisson <arnarbi at gmail.com>
>> > 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
>> > 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)
>> 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
>> > not
>> > 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.

What problems? If you read my message you can clearly see that I
pointed to a _solution_, namely asynchronous I/O. :) What I meant in
my last message is that I don't see how your suggestion improves on
the myriad of async solutions out there already (which are based on
select, poll, epoll, Windows ASIO, etc).


More information about the Stackless mailing list