Attempt at a `.trionics.TaskMngr` #23

Open

goodboy wants to merge 12 commits from oco_supervisor_prototype into ext_type_plds

Author	SHA1	Message	Date
Tyler Goodlet	c362603d15	Add `debug_mode: bool` control to task mngr Allows dynamically importing `pdbp` when enabled and a way for eventually linking with `tractor`'s own debug mode flag.	2025-03-27 15:53:17 -04:00
Tyler Goodlet	c169417085	Go all in on "task manager" naming	2025-03-27 15:53:16 -04:00
Tyler Goodlet	9bbe7ca945	More refinements and proper typing - drop unneeded (and commented) internal cs allocating bits. - bypass all task manager stuff if no generator is provided by the caller; i.e. just call `.start_soon()` as normal. - fix `Generator` typing. - add some prints around task manager. - wrap in `TaskOutcome.lowlevel_task: Task`.	2025-03-27 15:53:16 -04:00
Tyler Goodlet	c32520cb11	Ensure user-allocated cancel scope just works! Turns out the nursery doesn't have to care about allocating a per task `CancelScope` since the user can just do that in the `@task_scope_manager` if desired B) So just mask all the nursery cs allocating with the intention of removal. Also add a test for per-task-cancellation by starting the crash task as a `trio.sleep_forever()` but then cancel it via the user allocated cs and ensure the crash propagates as expected 💥	2025-03-27 15:53:16 -04:00
Tyler Goodlet	3613b6019c	Facepalm, don't pass in unecessary cancel scope	2025-03-27 15:53:16 -04:00
Tyler Goodlet	7b4accf53f	Do renaming, implement lowlevel `Outcome` sending As was listed in the many todos, this changes the `.start_soon()` impl to instead (manually) `.send()` into the user defined `@task_scope_manager` an `Outcome` from the spawned task. In this case the task manager wraps that in a user defined (and renamed) `TaskOutcome` and delivers that + a containing `trio.CancelScope` to the `.start_soon()` caller. Here the user defined `TaskOutcome` defines a `.wait_for_result()` method that can be used to await the task's exit and handle it's underlying returned value or raised error; the implementation could be different and subject to the user's own whims. Note that by default, if this was added to `trio`'s core, the `@task_scope_manager` would simply be implemented as either a `None` yielding single-yield-generator but more likely just entirely ignored by the runtime (as in no manual task outcome collecting, generator calling and sending is done at all) by default if the user does not provide the `task_scope_manager` to the nursery at open time.	2025-03-27 15:53:16 -04:00
Tyler Goodlet	5e25cf7399	Alias to `@acm` in broadcaster mod	2025-03-27 15:53:16 -04:00
Tyler Goodlet	78f51a3fd8	Initial prototype for a one-cancels-one style supervisor, nursery thing..	2025-03-27 15:53:16 -04:00
Tyler Goodlet	0279bb3311	Use shorthand nursery var-names per convention in codebase	2025-03-27 15:53:16 -04:00
Tyler Goodlet	106dca531a	Better separate service tasks vs. ctxs via methods Namely splitting the handles for each in 2 separate tables and adding a `.cancel_service_task()`. Also, - move `_open_and_supervise_service_ctx()` to mod level. - rename `target` -> `ctx_fn` params througout. - fill out method doc strings.	2025-03-27 15:53:16 -04:00
Tyler Goodlet	dfa2914c1d	Mv over `ServiceMngr` from `piker` with mods Namely distinguishing service "IPC contexts" (opened in a subactor via a `Portal`) from just local `trio.Task`s started and managed under the `.service_n` (more or less wrapping in the interface of a "task-manager" style nursery - aka a one-cancels-one supervision start). API changes from original (`piker`) impl, - mk `.start_service_task()` do ONLY that, start a task with a wrapping cancel-scope and completion event. \|_ ideally this gets factored-out/re-implemented using the task-manager/OCO-style-nursery from GH #363. - change what was the impl of `.start_service_task()` to `.start_service_ctx()` since it more explicitly defines the functionality of entering `Portal.open_context()` with a wrapping cs and completion event inside a bg task (which syncs the ctx's lifetime with termination of the remote actor runtime). - factor out what was a `.start_service_ctx()` closure to a new `_open_and_supervise_service_ctx()` mod-func holding the meat of the supervision logic. `ServiceMngr` API brief, - use `open_service_mngr()` and `get_service_mngr()` to acquire the actor-global singleton. - `ServiceMngr.start_service()` and `.cancel_service()` which allow for straight forward mgmt of "service subactor daemons".	2025-03-27 15:53:16 -04:00
Tyler Goodlet	896b2c73f4	Initial idea-notes dump and @singleton factory idea from `trio`-gitter	2025-03-27 15:53:16 -04:00