<div dir="ltr">I think we're getting way beyond the rationale Pau Freixes requested...<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 12:05 PM, Andrew Svetlov <span dir="ltr"><<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agree in general but current asyncio still may shoot your leg.<br>The solution (at least for my unittest example) might be in adding top level functions for running asyncio code (asyncio.run() and asyncio.run_forever() as Yury Selivanov proposed in <a href="https://github.com/python/asyncio/pull/465" target="_blank">https://github.com/python/<wbr>asyncio/pull/465</a>)<br>After this we could raise a warning in `asyncio.get_event_loop()` if the loop was not set explicitly by `asyncio.set_event_loop()`.</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 9:50 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Honestly I think we're in agreement. There's never a use for one loop running while another is the default. There are some rare use cases for multiple loops running but before the mentioned commit it was up to the app to ensure to switch the default loop when running a loop. The commit took the ability to screw up there out of the user's hand.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 9:57 AM, Andrew Svetlov <span dir="ltr"><<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, but with one exception: default event loop created on module import stage might co-exist with a loop created for test.<br>It leads to mystic hangs, you know.<br>Please recall code like:<br> class A:<div> mongodb = motor.motor_asyncio.<wbr>AsyncIOMotorClient()</div></div><div class="m_-9146858286225850834m_-436918151500104047HOEnZb"><div class="m_-9146858286225850834m_-436918151500104047h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 7:37 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, but not co-existing, I hope!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 9:25 AM, Andrew Svetlov <span dir="ltr"><<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Unit tests at least. Running every test in own loop is crucial fro tests isolation. </div><div><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 7:04 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Multiple loops in the same thread is purely theoretical -- the API allows it but there's no use case. It might be necessary if a platform has a UI-only event loop that cannot be extended to do I/O -- the only solution to do background I/O might be to alternate between two loops. (Though in that case I would still prefer a thread for the background I/O.)<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br>On Mon, Jun 12, 2017 at 8:49 AM, Pau Freixes <span dir="ltr"><<a href="mailto:pfreixes@gmail.com" target="_blank">pfreixes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">And what about the rationale of having multiple loop instances in the same thread switching btw them. Im still trying to find out what patterns need this... Do you have an example?<div dir="auto"><br></div><div dir="auto">Btw thanks for the first explanation</div></div><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049HOEnZb"><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049h5"><div class="gmail_extra"><br><div class="gmail_quote">El 12/06/2017 17:36, "Guido van Rossum" <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In theory it's possible to create two event loops (using new_event_loop()), then set one as the default event loop (using set_event_loop()), then run the other one (using run_forever() or run_until_complete()). To tasks running in the latter event loop, get_event_loop() would nevertheless return the former.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 4:39 AM, Pau Freixes <span dir="ltr"><<a href="mailto:pfreixes@gmail.com" target="_blank">pfreixes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry a bit of topic, but I would like to figure out why older python<br>
versions, prior this commit [1], the get_event_loop is not considered<br>
deterministic<br>
<br>
does anybody know the reason behind this change?<br>
<br>
<br>
[1] <a href="https://github.com/python/cpython/commit/600a349781bfa0a8239e1cb95fac29c7c4a3302e" rel="noreferrer" target="_blank">https://github.com/python/<wbr>cpython/commit/<wbr>600a349781bfa0a8239e1cb95fac29<wbr>c7c4a3302e</a><br>
<div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925HOEnZb"><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925h5"><br>
On Fri, Jun 9, 2017 at 6:07 PM, Ben Darnell <<a href="mailto:ben@bendarnell.com" target="_blank">ben@bendarnell.com</a>> wrote:<br>
> On Fri, Jun 9, 2017 at 11:51 AM Cory Benfield <<a href="mailto:cory@lukasa.co.uk" target="_blank">cory@lukasa.co.uk</a>> wrote:<br>
>><br>
>><br>
>><br>
>> My concern with multiple loops boils down to the fact that urllib3<br>
>> supports being used in a multithreaded context where each thread can<br>
>> independently make forward progress on one request. To establish that with a<br>
>> synchronous codebase you either need one event loop per thread or you need<br>
>> to spawn a background thread on startup that owns the only event loop in the<br>
>> process.<br>
><br>
><br>
> Yeah, one event loop per thread is probably the way to go for integration<br>
> with synchronous codebases. A dedicated event loop thread may perform better<br>
> but libraries that spawn threads are problematic.<br>
><br>
>><br>
>><br>
>> Generally speaking I’ve not had positive results with libraries spawning<br>
>> their own threads in Python. In my experience this has tended to lead to<br>
>> programs that deadlock mysteriously or that fail to terminate in the face of<br>
>> a Ctrl+C. So I tend to prefer to have users spawn their own threads, which<br>
>> would make me want a “one-event-loop-per-thread” model: hence, needing a<br>
>> loop parameter to pass around prior to 3.6.<br>
><br>
><br>
> You can avoid the loop parameter on older versions of asyncio (at least as<br>
> long as the default event loop policy is used) by manually setting your<br>
> event loop as current before calling run_until_complete (and resetting it<br>
> afterwards).<br>
><br>
> Tornado's run_sync() method is equivalent to asyncio's run_until_complete(),<br>
> and Tornado supports multiple IOLoops in this way. We use this to expose a<br>
> synchronous version of our AsyncHTTPClient:<br>
> <a href="https://github.com/tornadoweb/tornado/blob/62e47215ce12aee83f951758c96775a43e80475b/tornado/httpclient.py#L54" rel="noreferrer" target="_blank">https://github.com/tornadoweb/<wbr>tornado/blob/<wbr>62e47215ce12aee83f951758c96775<wbr>a43e80475b/tornado/httpclient.<wbr>py#L54</a><br>
><br>
> -Ben<br>
><br>
>><br>
>><br>
>> I admit that my concerns here regarding libraries spawning their own<br>
>> threads may be overblown: after my series of negative experiences I<br>
>> basically never went back to that model, and it may be that the problems<br>
>> were more user-error than anything else. However, I feel comfortable saying<br>
>> that libraries spawning their own Python threads is definitely subtle and<br>
>> hard to get right, at the very least.<br>
>><br>
>> Cory<br>
>> ______________________________<wbr>_________________<br>
>> Async-sig mailing list<br>
>> <a href="mailto:Async-sig@python.org" target="_blank">Async-sig@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/async-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/async-sig</a><br>
>> Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/<wbr>codeofconduct/</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Async-sig mailing list<br>
> <a href="mailto:Async-sig@python.org" target="_blank">Async-sig@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/async-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/async-sig</a><br>
> Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/<wbr>codeofconduct/</a><br>
><br>
<br>
<br>
<br>
</div></div><span class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925HOEnZb"><font color="#888888">--<br>
--pau<br>
</font></span><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925HOEnZb"><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925h5">______________________________<wbr>_________________<br>
Async-sig mailing list<br>
<a href="mailto:Async-sig@python.org" target="_blank">Async-sig@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/async-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/async-sig</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049m_-761179363942151325m_-7153373637396977925gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
</blockquote></div></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220m_2382542454619345793m_-3933544113557154049gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
______________________________<wbr>_________________<br>
Async-sig mailing list<br>
<a href="mailto:Async-sig@python.org" target="_blank">Async-sig@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/async-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/async-sig</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div><div dir="ltr">-- <br></div></div></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_-9146858286225850834m_-436918151500104047m_6220112265055037193m_-8006958203737700220gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
</blockquote></div></div></div><span class="m_-9146858286225850834m_-436918151500104047HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="m_-9146858286225850834m_-436918151500104047gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks,</div>Andrew Svetlov</div></div>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>