Ostap
So how about to make it intuitive: if workitem state is cooked then tracker is alive and some another workitem has to stop tracker or when workitem is dirty (then tracker stops too)?
This isn't currently possible with the way PDG works. There's an assumption that work spawned during the cook is cleaned up when the cook finishes, and there's also no way for a dirtying a work item to kill a long running process. We're discussing internally if this might be something we can implement, but since it would require some sigficiant changes I don't really have a time line for when it would be available.
Another considerations is how that sort of workflow would be handled when loading saved task graph state from disk, which would could contain a tracker work item in the cooked state. The tracker process wouldn't exist though, which conflicts with the assumption that a cooked tracker means the process exists. There would also need to be a mechanism for certain types of work items to reject the state specified in a saved task graph file.
For your use case, the best solution is likely to use the Python Script node to spawn the tracker in the way you want, i.e. using the subprocess module to spawn it, and let it run in the background. Then use another Python Script node to kill it at a point that makes sense in your graph.