[Async-sig] async/sync library reusage

[Pau Freixes]

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" <guido at 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 <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/600a349781bfa0a8239
>> e1cb95fac29c7c4a3302e
>>
>> 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/62e47215ce12aee83
>> f951758c96775a43e80475b/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/e8c419c2/attachment-0001.html>