This is an idea that just popped up randomly when looking through some
ray examples / discussion, particularly this trio issue comment:
python-trio/trio#2135 (comment)

import ray

ray.init()

@ray.remote
def task():

    import trio  # key part, importing in remote thread!

    async def sleeper():
        await trio.sleep(1)

    trio.run(sleeper)

task.remote()

Wait wut's the idea?

Can we support an embeddable API for launching the tractor runtime
inside any thread/process spawning system which can run trio?

The short answer is intuitively yes to me, but i'm sure there's quite
a bit that might have to go into it.

Motivations:

• bring cross-process SC to any parallel python system (including
  GIL-less python or a system that doesn't want to use tractor's
  thead/process spawning layer).
• allow for interchange-able actor spawning functionality in a
  different-framework-based library or platform, as in this ray
  example above, or something like
  numba.nogil if they ever decided
  to support compiling async python.
• bring parallelism to any python framework that didn't previously have
  it outside of GIL releasing extensions or threading usage.

High level API design

• we already support open_root_actor() as the entrypoint for starting
  the runtime, though maybe we can offer some even lower level hooks for
  this.
• we would need a way to swap out the spawning layer behind the scenes
  (dynamically) for ActorNursery.start_actor().
• allow for doing all the ._entry._trio_main() stuff through a public
  API in any target child process such that ._runtime._async_main()
  gets called / initialized correctly.
  • this is kinda like the callbacky parts of guest mode:

        trio.lowlevel.start_guest_run(
        main,
        run_sync_soon_threadsafe=run_sync_soon_threadsafe,
        done_callback=done_callback,
        # restrict_keyboard_interrupt_to_checkpoints=True,
    )

Obviously a lot more to go into in this section ..