Skip to content

Simplify the main GEM FSM

Summary

In the current architecture, the main GEM FSM application, GEMFSMApplication, is tightly coupled - not to say entagled - with the FSM managing class, GEMFSM. Since one cannot live without the other, it is worth wondering what is the rationale behind keeping those two classes separate. It adds a level of indirection for little, or no benefit.

In addition, the state transitions use a double asynchronous mechanism with two xDAQ workloops. Therefore, the transitions subject to race conditions which must be manually prevented (see these lines for example). Such behavior should try to be avoid as much as possible.

What is the expected correct behavior?

The code flow in the FSM should be easy to read and understand. Splitting features into multiples classes which depends so strongly on each other does not provide much benefit. Two solutions could be envisioned:

  1. Merge the two classes and remove the useless level of indirection.

  2. Improve the separation between the two classes. For example, the GEMFSM could act on an abstract class. The GEMFSMApplication would simply be one specific implementation.

In addition, the double asynchronous scheme should be removed if possible.

(Any merge request for this issue must include tests. They don't necessarily have to be run automatically - a xDAQ process will have to be running - and can be provided as a Python script cycling through the states via SOAP or JSON commands. Such a test will also be usable to cycle though the states of any application inheriting from GEMFSMApplication.)