>
> This is incorrect. "Create an async bounded context playpen" (what I
called "async" in my example)
> and "start a fiber/thread/task" (what I called "spawn") are two
*separate* operations, and > must remain so.
>
>
So, you use *async* to denote the context and *spawn* to create a coroutine.
Regarding the context, it seems there's some confusion with this term.
Let's try to separate it somehow.
For coroutines to work, a *Scheduler* must be started. There can be only
one *Scheduler* per OS thread. That means creating a new async task *does
not* create a new *Scheduler*.
Apparently, *async {}* in the examples above is the entry point for the
*Scheduler*.
>
> This is probably not the ideal way to structure it in practice, but it
should get the point across.
>
Sounds like a perfect solution.
However, the initialization order raises some doubts: it seems that all
required coroutines must be created in advance. Will this be convenient?
What if a service doesn’t want to initialize a coroutine immediately? What
if it’s not loaded into memory right away? *Lazy load.*
For example, we have a *Logger* service, which usually starts a coroutine
for log flushing. Or even multiple coroutines (e.g., a timer as well). But
the service itself might not be initialized and could start only on first
use.
Should we forbid this practice?
If you want to be a service, should you *always* initialize yourself
upfront?
Wait a minute. This resembles how an OS works. At *level 0*, the operating
system runs, while user-level code interacts with it via *interrupts*.
It's almost the same as *opening a channel in the ROOT context* and sending
a message through the channel from some *child context*. Instead of sending
a message directly to the Logger, we could send it to the *service manager*
through a channel.
Since the *channel was opened in the ROOT context*, all operations would
also execute in the *ROOT context*. And if the LOGGER was not initialized,
it would be initialized *from the ROOT context*.
Possible drawbacks:
1. It's unclear how complex this would be to implement.
2. If messages are sent via a channel, the logger *won't be able to
fetch additional data from the request environment*. All data must be
explicitly passed, or the *entire context* must be thrown into the
channel.
Needs more thought.
But in any case, the idea with the channel is good. It can cover many
scenarios.
Everything else is correct, I don’t have much to add.
---
Ed.
