Right now, the TaskHandler that supervises the handles for all subprocesses runs in one thread while the API handlers for the client run in their own threads. The process handles are currently bound to the TaskHandler's memory and not directly visible to the message handlers.
Due to the limitation of this design, any client commands that directly affect a process, such as pueue add --immediate, need to be forwarded via mpsc channel to the TaskHandler, as the message handlers have no access to the process handles.
This results in a short delay for such actions, which becomes a problem when scripting Pueue and also when writing tests.
Solutions
There're two approaches to solve this problem:
Put the child handles into the Mutex<State> that already exists. Right now, the State is always serialized to disk and serves as the point of restoration on restart. There were some problems with this approach, but I cannot remember them right now.
Introduce a second mutex that only holds the state of the TaskHandler.
In general, I would really like to only have a single mutex to prevent deadlocks, so if it's viable, I would prefer the first solution.
Tasks:
Move all local state from the TaskHandler to the State
Decouple all process handling functions from the TaskHandler into free functions
Make sure all of those functions take a locked state.
The state should be locked at as little locations as possible to prevent deadlocks.
As a general rule, the state may only get locked in:
Message handler functions
The TaskHandler's main loop
Merge the logic of the TaskHandler mpsc message handler logic and the client API message handlers, which should now do the process handling directly
Problem
Right now, the TaskHandler that supervises the handles for all subprocesses runs in one thread while the API handlers for the client run in their own threads. The process handles are currently bound to the TaskHandler's memory and not directly visible to the message handlers.
Due to the limitation of this design, any client commands that directly affect a process, such as
pueue add --immediate, need to be forwarded viampscchannel to the TaskHandler, as the message handlers have no access to the process handles.This results in a short delay for such actions, which becomes a problem when scripting Pueue and also when writing tests.
Solutions
There're two approaches to solve this problem:
Mutex<State>that already exists. Right now, theStateis always serialized to disk and serves as the point of restoration on restart. There were some problems with this approach, but I cannot remember them right now.In general, I would really like to only have a single mutex to prevent deadlocks, so if it's viable, I would prefer the first solution.
Tasks:
TaskHandlerto theStateTaskHandlerinto free functions