I need a way to run a coroutine when unloading a plugin

[rwols]

When unloading a plugin, some coroutine may need to run to shutdown connections gracefully (e.g., language clients closing connections gracefully with language servers).

Currently there's no way to run a coroutine when a plugin unloads.

I can perhaps use run_coroutine / call_coroutine in plugin_unloaded, but I'm seeing this creates problems with modules having been unloaded.

I think one way to solve this is to allow running a coroutine in the main thread. In the sense of stopping the loop temporarily, starting it from the main thread, and waiting for that one coroutine to be finished, then continue running in the sublime_aio thread.

[rwols]

I thought about this use case some years ago. See: https://github.com/sublimelsp/sublime_asyncio/blob/6a8eb2dbd36c72b34eb0078bc1b3cb96f1692acb/globalstate.py#L141-L197

[deathaxe]

You can borrow a solution from sublime_aio's on_exit handler.

Moving around the loop between threads is not an option as there are likely many plugins running code at the same time.

[deathaxe]

A solution could look like...

import asyncio
import sublime_aio
from threading import Event


async def unload_plugin():
    await asyncio.sleep(2.0)
    return True


def plugin_unloaded():
    event = Event()
    future = sublime_aio.run_coroutine(unload_plugin())
    future.add_done_callback(lambda _: event.set())
    if not event.wait(timeout=20.0):
        return None

    exc = future.exception()
    if exc:
        raise exc

    # return future.result()

[rwols]

Moving around the loop between threads is not an option as there are likely many plugins running code at the same time.

I'm not sure what you mean here. There is only ever one task "running" in an asyncio event loop. All other tasks are suspended.

I'll use the example!

[rwols]

Another thing to think about: how to deal with destruction of EventListener upon plugin unload, and ViewEventListener upon plugin_unload and/or tab closing in the UI?

Should coroutines spawned by EventListener and ViewEventListener keep running? I think they should be collectively cancelled (somehow).

[rwols]

Well, except for the special EventListener.on_exit.

[deathaxe]

I'm not sure what you mean here. There is only ever one task "running"

Pending, queued, completed. A caller has no control about the state of tasks or when they are executed. I see your example shutting down the loop, but letting plugins do so is weird at least. The main event loop is just meant to and designed to run forever.

Should coroutines spawned by EventListener and ViewEventListener keep running? I think they should be collectively cancelled (somehow).

Likely any of them raises an exception due to view no longer being valid. This is like executing on_..._async handlers of ViewEventListeners, which are not cancelled if view is closed.

Once a coro raises, the whole task is cancelled automatically. A Listener instance is garbage collected only after all pending tasks completed. sublime_aio has no control about when ST decides to create/attach or detach/delete ViewEventListener instances and so can't know when to cancel them. It could probably intercept the is_applicable() method, but well. If you want async code, live with its consequences.

[rwols]

I have bad news. using event.wait in plugin_unloaded just blocks until the timeout. My first instinct is that this is due to some print statements that internally need some kind of lock on the main thread as well...

[deathaxe]

Any sublime.set_timeout() pushing anything to main thread would be enough. Nothing must ever call back to main thread then. But that's a classical deadlock issue. Nothing caused by sublime_aio.