Hi Larry, On Fri, Oct 10, 2008 at 00:54, Larry Dickson <[EMAIL PROTECTED]> 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 _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
