<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">Not sure if it helps, but I got something working for the problem I was experiencing by detecting if there was a currently running event loop, and then at the synchronous call points, creating and running a new loop on a separate thread. This makes the object in question synchronous or asynchronous but not both.

<div><br /></div>

<div>This was kind of a pain in the butt though and it blocks the outer loop anyway.</div>

<div><br /></div>

<div>I think I’m in favor of a configurable option to allow separate nested loops if possible. In the narrow situation I am concerned with of allowing library writers to provide synchronous APIs to otherwise asynchronous code that has to run in a world it can’t make usage demands of, it’s a good solution. In that scenario, I think the details of the underlying inner event loop likely won’t leak out to the outer event loop (creating a cross event loop dependency) when it’s being used synchronously.</div>

</div>

<div name="messageSignatureSection"><br />

-Dan Nugent</div>

<div name="messageReplySection">On Mar 25, 2019, 21:59 -0400, Dima Tisnek <dimaqq@gmail.com>, wrote:<br />

<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">End-user point of view, a.k.a. my 2c:<br />

<br />

re more worrisome scenario: if "objects" from two event loops depends<br />

on each other, that's unsolvable in general case. On the other hand,<br />

what OP wanted, was akin to DAG-like functionality or locking<br />

hierarchy. Naive implementation would block caller callbacks until<br />

callee completes, but that may be what the user actually wanted (?).<br />

<br />

re ipython notebook state reuse across cells: that's a whole different<br />

can of worms, because cells can be re-evaluated in arbitrary order. As<br />

a user I would expect my async code to not interfere with ipynb<br />

internal implementation. In fact, I'd rather see ipynb isolated into<br />

own thread/loop/process. After all, I would, at times like to use a<br />

debugger.<br />

(full disclosure: I use debugger in ipython and it never really worked<br />

for me in sync notebook, let alone async).<br />

<br />

re original proposal: async code calls a synchronous function that<br />

wants to do some async work and wait for the result, for example,<br />

telemetry bolt-on. I would expect the 2 event loops to be isolated.<br />

Attempting to await across loop should raise an exception, as it does.<br />

When some application wants to coordinate things that happen in<br />

multiple event loops, it should be the application's problem.<br />

<br />

<br />

I think this calls for a higher-level paradigm, something that allows<br />

suspension and resumption of entire event loops (maybe executors?) or<br />

something that allows several event loops to run without being aware<br />

of each other (threads?).<br />

<br />

<br />

I feel that just adding the flag to allow creation / setting of event<br />

loop is not enough.<br />

We'd need at least a stack where event loops can be pushed and popped<br />

from, and possibly more...<br />

<br />

Cheers,<br />

D.<br />

<br />

On Tue, 26 Mar 2019 at 09:52, Glyph <glyph@twistedmatrix.com> wrote:<br />

<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;"><br />

Allowing reentrant calls to the same loop is not a good idea IMO. At best, you'll need to carefully ensure that the event loop and task implementations are themselves reentrancy-safe (including the C accelerators and third parties like uvloop?), and then it just invites subtle issues in the applications built on top of it. I don't think there's a good reason to allow or support this (and nest_asyncio should be heavily discouraged). I do, however, think that PBP is a good enough reason to allow opt-in use of multiple event loops nested inside each other (maybe something on the EventLoopPolicy for configuration?).<br />

<br />

<br />

+1 to all of this.<br />

_______________________________________________<br />

Async-sig mailing list<br />

Async-sig@python.org<br />

https://mail.python.org/mailman/listinfo/async-sig<br />

Code of Conduct: https://www.python.org/psf/codeofconduct/<br /></blockquote>

</blockquote>

</div>

</body>

</html>