[Stackless] Stackless based replacement

[Arnar Birgisson]

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).

cheers,
Arnar