ATEF should show the currently running processes, and give users the ability to cancel steps that are stuck and/or taking a long time. This makes the most sense for active checkouts, since timeouts in passive checkouts are quick. (probably too quick to react to)
The head-in-the-clouds vision is a task-manager type window where a user can see the steps that are in process (e.g. a set-value step). This could be abbreviated as a single-line status output at the bottom of the window.
Possible Solution / My thoughts
Currently we handle concurrency in a few ways. We have:
asyncio coroutines
passive checkout .check()
active checkout .run()
QThreads
(Basically any processing we don't want in the gui thread, including the above co-routines)
run-tree generation
ophyd/happi viewer's _DevicePollThread
threading.Thread
ArchiveHelper, searches for PVs in the archiver
While it's possible to track one type of process, since we have all of the above it becomes less clear. (e.g. if we bundled the asyncio coroutines into tasks, we could use asyncio.all_tasks() to get the active tasks, but tasks are also managed by an asyncio event loop and we actually want active checkout tasks to run sequentially.... 😵💫 )
Do we then need to roll our own process manager? A BusyCursorThread-type thread that on instantiation we hook completion signals to? Add abort functionality to each and every process we dispatch to that thread?
Keeping track of these thread-type objects needs to be done carefully (I'm just scarred by all the teardown test-suite errors 😬 ). Gather them in a simple collection of some sort?
Coming back to this I'm thinking it's probably just a roll-our-own angle rather than use the wide and disparate collection methods.
Expected Behavior
ATEF should show the currently running processes, and give users the ability to cancel steps that are stuck and/or taking a long time. This makes the most sense for active checkouts, since timeouts in passive checkouts are quick. (probably too quick to react to)
The head-in-the-clouds vision is a task-manager type window where a user can see the steps that are in process (e.g. a set-value step). This could be abbreviated as a single-line status output at the bottom of the window.
Possible Solution / My thoughts
Currently we handle concurrency in a few ways. We have:
.check().run()_DevicePollThreadthreading.ThreadWhile it's possible to track one type of process, since we have all of the above it becomes less clear. (e.g. if we bundled the asyncio coroutines into tasks, we could use
asyncio.all_tasks()to get the active tasks, but tasks are also managed by an asyncio event loop and we actually want active checkout tasks to run sequentially.... 😵💫 )Do we then need to roll our own process manager? A BusyCursorThread-type thread that on instantiation we hook completion signals to? Add abort functionality to each and every process we dispatch to that thread?
Keeping track of these thread-type objects needs to be done carefully (I'm just scarred by all the teardown test-suite errors 😬 ). Gather them in a simple collection of some sort?
Coming back to this I'm thinking it's probably just a roll-our-own angle rather than use the wide and disparate collection methods.
Context
Jira
A highly requested feature, but seems like quite a large refactor.
Your Environment
pcds-5.7.3, atef-1.0.0