GT Architecture

Reference documentation

The way GT runs, responds to RC, and deals with partitions

The NovaGlobalTrigger is designed to provide all the triggers you would ever want for a given partition. A run will always have the same configuration. So, a NovaGlobalTrigger gets all its config on startup. If you want to re-configure it, it should be restarted. If you want to simply start a new run with the same parameters, NovaGlobalTrigger should simply reset its trigger number counters to zero and go.

So how do you get partitions setup?

NGTMaster is designed to do this - handle the creating and destroying of partitions and fielding configuration requests from RC. If asked to create a partition, it will spin off a NovaGlobalTrigger on that partition. If asked to release one, it kills that program. For re-configuring, it kills and restarts with the new config.

It does this through the command line. NovaGlobalTrigger -p partno starts an instance on partion number "partno". NovaGlobalTrigger -c thatfile uses the xml file "thatfile" for its configuration.

The class "GT_Inst" (a threadsafe singleton) is available to keep track of GT processes in various partitions.

The RC handling code from Kurt via Adam lives in NGTMasterRC.cpp (for the master controller) and NGTRC.cpp (for the GT instance). This code runs as a thread, fields commands from RC, and makes their respective programs dance accordingly.

In NovaGlobalTrigger, the client needs to respond only to run state commands, but ignore other RC commands. It should also trap signals to exit more cleanly, although I think the main consequence of this is simply stderr spew which can be ignored. NGTMaster ignores the run state commands which NovaGlobalTrigger deals with, but handles all the pre-partition states and verifies that the config files it's been told to load up in a NovaGlobalTrigger for a partition actually exist.