<br><br><div class="gmail_quote">On Tue, Oct 23, 2012 at 12:54 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

But does it let you use any Windows APIs?<br>
<br></blockquote><div><br></div><div>That I don't know.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 23, 2012 at 9:09 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> Go is available for Windows: <a href="http://golang.org/doc/install#windows" target="_blank">http://golang.org/doc/install#windows</a><br>
><br>
> On Tue, Oct 23, 2012 at 10:48 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>><br>
>> Thanks for the pointer to and description of libuv; it had come up in<br>
>> my research yet but so far I have not looked it up actively. Now I<br>
>> will. Also thanks for your reminder of the Goroutine model -- this is<br>
>> definitely something to look at for inspiration as well. (Though does<br>
>> Go run on Windows? Or is it part of a secret anti-Microsoft plan? :-)<br>
>><br>
>> --Guido<br>
>><br>
>> On Tue, Oct 23, 2012 at 12:19 AM, Benoit Chesneau <<a href="mailto:benoitc@gunicorn.org">benoitc@gunicorn.org</a>><br>
>> wrote:<br>
>> ><br>
>> > On Oct 22, 2012, at 4:59 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>> ><br>
>> >> On Sun, Oct 21, 2012 at 10:30 PM, Steve Dower<br>
>> >> <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>> wrote:<br>
>> >> [Stuff about Futures and threads]<br>
>> >><br>
>> >> Personally, I'm interested in designing a system, including an event<br>
>> >> loop, where you can rely on the properties of cooperative scheduling<br>
>> >> to avoid ever touching (OS) threading locks. I think such a system<br>
>> >> should be "pure" and all interaction with threads should be mediated<br>
>> >> by the event loop. (It's okay if this means that the implementation of<br>
>> >> the event loop must at some point acquire a threading lock.) The<br>
>> >> Futures used by the tasks to coordinate amongst themselves should not<br>
>> >> require locking -- they should themselves be able to rely on the<br>
>> >> guarantees of the event loop not to invoke multiple callbacks in<br>
>> >> parallel.<br>
>> >><br>
>> >> IIUC you can do this on Windows with IOCP too, simply by only having a<br>
>> >> single thread reading events.<br>
>> >><br>
>> ><br>
>> > Maybe it is worth to have a look on libuv and the way it mixes threads<br>
>> > and  and event loop [1]. Libuv is one of the good event loop around able to<br>
>> > use IOCP and other events systems on other arch (kqueue, …) and I was<br>
>> > thinking when reading all the exchange around that it would perfectly fit in<br>
>> > our cases. Or at least something like it:<br>
>> ><br>
>> > - It provides a common api for IO watchers: read, write, writelines,<br>
>> > readable, writeable that can probably be extend over remote systems<br>
>> > - Have a job queue system for threds that is working mostly like the<br>
>> > Futures but using the event loop<br>
>> ><br>
>> > In any case there is a pyuv binding [2] if some want to test. Even a<br>
>> > twisted reactor [3]<br>
>> ><br>
>> > I myself toying with the idea of porting the Go concurrency model to<br>
>> > Python [4] using greenlets and pyuv. Both the scheduler and the way IOs are<br>
>> > handled:<br>
>> ><br>
>> > - In Go all coroutines are independent from each others and can only<br>
>> > communicate via channel. Which has the advantage to allows them to run on<br>
>> > different threads when one is blocking. In normal case they are mostly<br>
>> > working like grrenlets on a single thread and are simply scheduled in a<br>
>> > round-robin way. (mostly like in stackless). On the difference that<br>
>> > goroutines can be executed in parallel. When one is blocking another thread<br>
>> > will be created to handle other goroutines in the runnable queue.<br>
>> ><br>
>> > - For I/Os it exists a common api to all Connections and Listeners (Conn<br>
>> > & Listen classes) that generally ask on a poll server. This poll server has<br>
>> > for only task to register FDs and wake up the groutines that wait on read or<br>
>> > fd events. This this poll server is running in a blocking loop it is<br>
>> > automatically let by the scheduler in a thread. This pol server could be<br>
>> > likely be replaced by an event loop if someone want.<br>
>> ><br>
>> > In my opinion the Go concurrency & memory model [5] could perfectly fit<br>
>> > in the Python world and I'm surprised none already spoke about it.<br>
>> ><br>
>> > In flower greenlets could probably be replaced by generators but i like<br>
>> > the API proposed by any coroutine pattern. I wonder if continulets [6]<br>
>> > couldn't be ported in cpython to handle that…<br>
>> ><br>
>> > - benoît<br>
>> ><br>
>> ><br>
>> > [1] <a href="http://nikhilm.github.com/uvbook/threads.html" target="_blank">http://nikhilm.github.com/uvbook/threads.html</a> &<br>
>> > <a href="http://github.com/joyent/libuv" target="_blank">http://github.com/joyent/libuv</a><br>
>> > [2] <a href="https://github.com/saghul/pyuv" target="_blank">https://github.com/saghul/pyuv</a><br>
>> > [3] <a href="https://github.com/saghul/twisted-pyuv" target="_blank">https://github.com/saghul/twisted-pyuv</a><br>
>> > [4] <a href="https://github.com/benoitc/flower" target="_blank">https://github.com/benoitc/flower</a><br>
>> > [5] <a href="http://golang.org/ref/mem" target="_blank">http://golang.org/ref/mem</a><br>
>> > [6] <a href="http://doc.pypy.org/en/latest/stackless.html#continulets" target="_blank">http://doc.pypy.org/en/latest/stackless.html#continulets</a><br>
>><br>
>><br>
<span class="HOEnZb"><font color="#888888">>><br>
>> --<br>
>> --Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
>> _______________________________________________<br>
>> Python-ideas mailing list<br>
>> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
>> <a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</font></span></blockquote></div><br>