Conversation
|
@guilledk so I think we can probably just land this since it's small enough and seems to mostly still work 😂 the one last thing I was hoping to get going was running what you think? |
| @@ -0,0 +1,141 @@ | |||
| """ | |||
There was a problem hiding this comment.
Ahh we need license header..
| ] | ||
|
|
||
|
|
||
| async def spawn_brokerd( |
There was a problem hiding this comment.
Do you think it's maybe just worth generalizing this spawn logic now?
For example we can have a spawn_daemon(name: str) and then just pass the module list in each case?
There was a problem hiding this comment.
Yeah that might be worth doing, easier to abstract shared behavoirs
There was a problem hiding this comment.
Kinda started this with the Services type but we probably want to factor out the spawn_<service>d() code somewhat eventually as needed.
|
Need to cherry-pick in a few commits from cached_feeds branch still. Will probably delay the spawn api formalizing for another PR just to start keeping things small. |
30152c7 to
69f6538
Compare
|
@guilledk pretty sure this is ready to land as well 🏄🏼 |
| ] | ||
|
|
||
|
|
||
| # @dataclass |
There was a problem hiding this comment.
heh lingering comment.
Refactor maybe_spawn_brokerd to adapt to new process tree structure and add a ``maybe_open_pikerd``.
The direct open is needed for running `pikerd` cmd and the ems spawn point is the first step toward detaching UI based order entry from the engine itself.
Add a `Services` nurseries container singleton for spawning sub-daemons inside the long running `pikerd` tree. Bring in `brokerd` spawning util funcs to start getting eyes on what can be factored into a service api.
2 participants
Rebase and fixes to port to new clearing system of #149.
@guilledk I think this is probably the smoothest way forward to avoid waiting on you to rebase 😂
We can both work off this branch now.