[Async-sig] async/sync library reusage

[Guido van Rossum]

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 <pfreixes at 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 <ben at bendarnell.com> wrote:
> > On Fri, Jun 9, 2017 at 11:51 AM Cory Benfield <cory at 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 at 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 at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20170612/a0cc9906/attachment.html>