Usecase for nested run (and blocking outside runer)

[Carreau]

Hi There,

I'm working on adding some Async support to IPython, which basically convert the core to most of it being coroutine. I'm ending up with a use case where I'd actually like to call trio.run() from within trio.run() which you can't because of :

if hasattr(GLOBAL_RUN_CONTEXT, "runner"):
        raise RuntimeError("Attempted to call run() from inside a run()")

Yes, I know, run inside run is a footgun, but in my case it's to call nested IPython.embed(), so you literally want to halt the outer embed, and start a new loop;
I'm using the following that seem to work:

from contextlib import contextmanager
 _sentinel = object()
@contextmanager
def new_context():
    import trio._core._run as tcr
    old_runner = getattr(tcr.GLOBAL_RUN_CONTEXT, 'runner', _sentinel)
    old_task = getattr(tcr.GLOBAL_RUN_CONTEXT, 'task', None)
    if old_runner is not _sentinel:
        del tcr.GLOBAL_RUN_CONTEXT.runner
    tcr.GLOBAL_RUN_CONTEXT.task = None
    yield
    if old_runner is not _sentinel:
        tcr.GLOBAL_RUN_CONTEXT.runner = old_runner
    tcr.GLOBAL_RUN_CONTEXT.task = old_task

Is there a better way ?
If not, does that seem "Ok-ish", or do you see any other things I need to watch out for ?

I know this is internals API, and I'm not requesting it to be stable, if they change, well so be it, and I'll mark the nested-embed in IPython as "Brittle and depends on some non-vetted code", but still really like to keep the functionality for some users.

Thanks.

[njsmith]

I'm having trouble understanding the use case... you have a trio program, that does a blocking/synchronous call to IPython.embed, and then inside that blocking call you want to do another call to trio.run, so the user can use direct await calls inside the embedded interpreter but these await calls are running on an entirely different loop than the main program, so if you they try to actually await any of the stuff in the program you're embedded in then things will explode dramatically... this seems like it will confuse people a lot, and not be very useful?

I can understand why you'd want to do a regular synchronous IPython.embed to freeze an async program and poke around in it, without async support inside the embedded interpreter. And I can see why you'd want to support some kind of await IPython.async_embed() that re-uses the ambient loop, so you can interactively explore the async program and do stuff like call await that_queue.put(...) to poke at the live code while it runs. But I don't get why nesting a second run would be what you want (either for trio or for other loops).

Am I missing something?

[smurfix]

Why don't you freeze the outer loop with a threading.Condition, and start the "inner" loop (presumably something that inspects the outer program's data or whatever) in a new thread?

That way you'd have a clean separation between the two, and the option of continuing the outer loop without terminating the inspector.

[Carreau]

Am I missing something?

Yes, And I wasn't clear above. I'm not speaking of IPython.async_embed(), but because a large chunk of core of IPython itself is async, we basically need to run an event loop. That is to say we don't use exec(user_code, globals(), locals()), but await exec(user_code, globals(), locals() (so to speak).
Many of our internals methods are now async, so even running synchronous code requires a loop/runner. Thus IPython.embed function is itself roughly:

def embed(...):
      loop = choose_a_loop()
      Import IPython
      loop.run(IPython.shell, *args, **kwargs)

You'll have noticed that a limitation to use trio in nested-embed IPython will be that you can only run trio async code in it, but it's a limitation I'm happy to have for now.

await IPython.async_embed() would be good, but ... not now.

Why don't you freeze the outer loop with a threading.Condition, and start the "inner" loop (presumably something that inspects the outer program's data or whatever) in a new thread?

That way you'd have a clean separation between the two, and the option of continuing the outer loop without terminating the inspector.

Because much of user code don't really like thread (and our not everywhere, we often have issues with SQlite for history). So I'd like to not use thread of possible.

I have a mitigation, which is to say that curio and trio are optional library, that you can't nest more than 3 instances and that each need to run in a different runner.

[njsmith]

Many of our internals methods are no[w] async, so even running synchronous code requires a loop/runner.

Ah, I get it.

You'll have noticed that a limitation to use trio in nested-embed IPython will be that you can only run trio async code in it, but it's a limitation I'm happy to have for now.

I think it would actually be less confusing if the nested-embed IPython didn't support running user async code at all. If embed lets users run async code, then they'll think that it's async_embed, when it really isn't.

Maybe IPython should have a "synchronous only" mode, where user await doesn't work (basically like how it works now without your changes, at least from the user point of view). And maybe this mode should be automatically enabled by IPython.embed()?

A nice thing about a "synchronous only" mode is that it doesn't matter what coroutine runner you use, because the user can't see the coroutine runner anyway. You might even be able to use The World's Worst Coroutine Runner:

def run(async_fn, *args):
    coro = async_fn(*args)
    try:
        coro.send(None)
    except StopIteration as exc:
        return exc.value
    else:
        raise RuntimeError(f"{async_fn.__name__!r} needs a real async loop")

async def cake():
    print("The async is a lie")

run(cake)

This works fine as long as async_fn never actually tries to suspend itself – it can await other functions, use async iterators, whatever; it just has to make sure that it ultimately ends up using time.sleep instead of trio.sleep or asyncio.sleep, uses blocking I/O calls instead of trio/asyncio's I/O primitives, etc. Depending on how IPython is using these libraries, this might actually be pretty easy to do?

Technically speaking, it would be easy to support nested calls to trio.run. If you really need it then we could remove the check, or maybe add an I-know-what-I'm-doing option like trio.run(..., allow_nested=True) or something. But first I want to be sure you really do need it :-).

[Carreau]

are no[w] async

GRahh... I have when my finger are 4 keys wide.

Maybe IPython should have a "synchronous only" mode, where user await doesn't work (basically like how it works now without your changes, at least from the user point of view). And maybe this mode should be automatically enabled by IPython.embed()?

A nice thing about a "synchronous only" mode is that it doesn't matter what coroutine runner you use, because the user can't see the coroutine runner anyway. You might even be able to use The World's Worst Coroutine Runner:

Well, that seem like a good idea, at least as a default for IPython embed, module. We're not using any async libraries internally (yet), and there are plenty of other footguns if you want to configure IPython anyway.

I'll use your "worst coroutine runner" with some modifcation for now.

[njsmith]

OK, cool, I'll close this for now then, and we can always revisit it later.

[Carreau]

@njsmith I'm going to likely make a blog announce for IPython 7.0 and async support. Any specific snippet of code you'd like in a screenshot to show-of trio ?

[njsmith]

I guess you could do something like:

%%time
async def do_stuff():
    await trio.sleep(1)
    print("Slept for 1 second!")

async with trio.open_nursery() as nursery:
    nursery.start_soon(do_stuff)
    nursery.start_soon(do_stuff)

which should print something like: "Slept for 1 second! Slept for 1 second! Time: 1.002 seconds", so it shows off basic concurrency + ipython magics working together?

...uh, they do work together, right? :-)

(Anyone else have any suggestions they want to throw in?)

[Carreau]

which should print something like: "Slept for 1 second! Slept for 1 second! Time: 1.002 seconds", so it shows off basic concurrency + ipython magics working together?

...uh, they do work together, right? :-)

I hadn't thought of that, and actually %%time is one of the magics that does not work with async, as it does its own ast-parsing transformation, and exec, same for %%timeit and prun. Those are things we can work on. But I'm not sure I want to delay a major release for that. Hopefully people will complain and come to fix the code.

[kawing-chiu]

@njsmith Hi. I think I have found another use case, it's related to multiprocessing: I have a WorkerManager class that uses trio. Its job is to run and manage several workers using multiprocessing. Each of the workers, however, is also independent class that uses trio . So when the worker subprocesses start, the worker classes call trio.run() and then raise the nested run exception.

[njsmith]

@kawing-chiu sorry we missed your message. I don't quite understand what you're doing or how this is triggering a nested run exception... Different calls to run in different subprocesses shouldn't affect each other. Can you open a new issue with more details?

[oakkitten]

i ran into this while testing with pytest-trio. i'm launching another process that is using trio using multiprocessing, but since i'm launching it from an async fixture, i get this error. i suppose the issue is that multiprocessing forks, so the context remains

[njsmith]

@oakkitten: Split off the multiprocessing/fork issue into #1614.

In retrospect, I bet that this is the same issue @kawing-chiu upthread ran into last year...