In Tornado this comes up sometimes in initialization scenarios:
def main():
# Since main is synchronous, we need a synchronous HTTP client
with tornado.httpclient.HTTPClient() as client:
# HTTPClient creates its own event loop and runs it behind the
scenes.
# This is not the same as the event loop under which main() is
running.
resp = client.fetch(url)
if __name__ == '__main__':
IOLoop.current().add_callback(main)
IOLoop.current().start()
This is never an ideal scenario (it would be better to make main() a
coroutine and use an async HTTP client), but it does sometimes come up as
the most expedient option.
This scenario is also why methods like EventLoop.is_running() tend to be
misguided - the question of "can I use this event loop" is not directly
related to "is this event loop running".
-Ben
On Mon, Jun 12, 2017 at 11:58 AM Guido van Rossum <gu...@python.org> wrote:
> 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.)
>
> On Mon, Jun 12, 2017 at 8:49 AM, Pau Freixes <pfrei...@gmail.com> wrote:
>
>> 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?
>>
>> Btw thanks for the first explanation
>>
>> El 12/06/2017 17:36, "Guido van Rossum" <gu...@python.org> escribió:
>>
>>> 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.
>>>
>>> On Mon, Jun 12, 2017 at 4:39 AM, Pau Freixes <pfrei...@gmail.com> wrote:
>>>
>>>> Sorry a bit of topic, but I would like to figure out why older python
>>>> versions, prior this commit [1], the get_event_loop is not considered
>>>> deterministic
>>>>
>>>> does anybody know the reason behind this change?
>>>>
>>>>
>>>> [1]
>>>> https://github.com/python/cpython/commit/600a349781bfa0a8239e1cb95fac29c7c4a3302e
>>>>
>>>> On Fri, Jun 9, 2017 at 6:07 PM, Ben Darnell <b...@bendarnell.com> wrote:
>>>> > On Fri, Jun 9, 2017 at 11:51 AM Cory Benfield <c...@lukasa.co.uk>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> My concern with multiple loops boils down to the fact that urllib3
>>>> >> supports being used in a multithreaded context where each thread can
>>>> >> independently make forward progress on one request. To establish
>>>> that with a
>>>> >> synchronous codebase you either need one event loop per thread or
>>>> you need
>>>> >> to spawn a background thread on startup that owns the only event
>>>> loop in the
>>>> >> process.
>>>> >
>>>> >
>>>> > Yeah, one event loop per thread is probably the way to go for
>>>> integration
>>>> > with synchronous codebases. A dedicated event loop thread may perform
>>>> better
>>>> > but libraries that spawn threads are problematic.
>>>> >
>>>> >>
>>>> >>
>>>> >> Generally speaking I’ve not had positive results with libraries
>>>> spawning
>>>> >> their own threads in Python. In my experience this has tended to
>>>> lead to
>>>> >> programs that deadlock mysteriously or that fail to terminate in the
>>>> face of
>>>> >> a Ctrl+C. So I tend to prefer to have users spawn their own threads,
>>>> which
>>>> >> would make me want a “one-event-loop-per-thread” model: hence,
>>>> needing a
>>>> >> loop parameter to pass around prior to 3.6.
>>>> >
>>>> >
>>>> > You can avoid the loop parameter on older versions of asyncio (at
>>>> least as
>>>> > long as the default event loop policy is used) by manually setting
>>>> your
>>>> > event loop as current before calling run_until_complete (and
>>>> resetting it
>>>> > afterwards).
>>>> >
>>>> > Tornado's run_sync() method is equivalent to asyncio's
>>>> run_until_complete(),
>>>> > and Tornado supports multiple IOLoops in this way. We use this to
>>>> expose a
>>>> > synchronous version of our AsyncHTTPClient:
>>>> >
>>>> https://github.com/tornadoweb/tornado/blob/62e47215ce12aee83f951758c96775a43e80475b/tornado/httpclient.py#L54
>>>> >
>>>> > -Ben
>>>> >
>>>> >>
>>>> >>
>>>> >> I admit that my concerns here regarding libraries spawning their own
>>>> >> threads may be overblown: after my series of negative experiences I
>>>> >> basically never went back to that model, and it may be that the
>>>> problems
>>>> >> were more user-error than anything else. However, I feel comfortable
>>>> saying
>>>> >> that libraries spawning their own Python threads is definitely
>>>> subtle and
>>>> >> hard to get right, at the very least.
>>>> >>
>>>> >> Cory
>>>> >> _______________________________________________
>>>> >> Async-sig mailing list
>>>> >> Async-sig@python.org
>>>> >> https://mail.python.org/mailman/listinfo/async-sig
>>>> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Async-sig mailing list
>>>> > Async-sig@python.org
>>>> > https://mail.python.org/mailman/listinfo/async-sig
>>>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> --pau
>>>> _______________________________________________
>>>> Async-sig mailing list
>>>> Async-sig@python.org
>>>> https://mail.python.org/mailman/listinfo/async-sig
>>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>>
>>>
>>>
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
