More sophistication/flexibility should be offered concerning the order of transitions to processes
Motivated by ever-more-complex process layouts (multiple subsystems, DFO usage, etc.) Kurt and I discussed ways to improve the order in which DAQInterface sends transitions to the artdaq processes. Currently, what happens is that transitions are sent to one class of process, then another class, then another class - e.g., on start, to Dispatchers, then to DataLoggers, then to EventBuilders, then to BoardReaders. The order of class depends, of course, on the transition - on stop, the order is the reverse of what's on start. The only additional sophistication is that users have the option of deciding in what order the individual boardreader processes receive commands (see Issue #16637).
However, there are two realities which exist now which didn't exist when this original scheme was developed:
1) The ability to run with multiple subsystems.
2) The addition of new process types, e.g., the DFO
An obvious action to take would be to allow ultimate flexibility to the user on when processes receive transitions. Another action is to think carefully about what sort of default behavior we want when multiple subsystems are involved. We want to make sure that DAQInterface's transition order is able to handle the latest, most complex possible process arrangements.
#1 Updated by John Freeman about 2 months ago
Here are some further thoughts. Let's take as a model four subsystems, each containing boardreaders, eventbuilders and dataloggers. We'll label the four subsystems A, B, C and D. Subsystem A is a child of subsystems B and C. Subsystem B is a child of subsystem D. In other words:
D \ B C \ / A
It seems like on the start transition, really the main thing we'd care about is that the boardreaders across all four subsystems get the start transition after all the other process types- would it matter if the eventbuilders got the start transition before the dataloggers, as long as boardreaders remained in the configured state and thus weren't sending data? Currently, the dataloggers receive the start transition, and then afterwards, the eventbuilders receive the start transition - but this distinction may be unnecessary, in which case we could parallelize the eventbuilders/dataloggers' start transition and thereby hopefully speed up the overall start.
The stop transition is a bit trickier. This is because the eventbuilders in A are receiving data from the eventbuilders in B and C, and furthermore, the eventbuilders in B are receiving data from the eventbuilders in D. So I suppose one question is, in this scenario would we want to first stop the eventbuilders in D, then stop the eventbuilders in B and C, and then stop the eventbuilders in A? This would be as opposed to the current behavior, which is where a stop is sent to all eventbuilders across the four subsystems at once.
That question, of course, refers to default behavior. The next question is, what sort of interface should be offered to users to allow them to exercise fine-grained control over the relative order of process stops/starts? Right now, there's the "boardreader_priorities" option introduced in Issue #16637 and documented in the DAQInterface manual at https://cdcvs.fnal.gov/redmine/projects/artdaq-utilities/wiki/The_settings_file_reference . This allows users to set the relative order in which specific boardreaders receive the start transition. Kurt pointed out that we might want a different order on stop, so it seems we could add a "boardreader_priorities_on_stop" option as well. Also, given that some eventbuilders are DFOs, should we introduce an "eventbuilder_priorities" option? Or is the behavior of DFOs well-understood enough that DAQInterface can give it some default transition order, e.g. always before or always after the other eventbuilder types?
Another question is, do we want to give users complete control over the transition order, or is this an example of https://en.wikipedia.org/wiki/You_aren't_gonna_need_it? I could add options called "overriding_priorities" and "overriding_priorities_on_stop" in which users would be allowed to specify any order of transitions to the processes, as long as the set of regexes provided covered all the processes in a run, but would this ever be used or would the options discussed in the above paragraphs be all users would realistically need - and not enough rope to hang themselves by?