> > (main clock) process to make sure the logger has finished logging all events before continuing to stop readout
>
> of other frontends. There is also a timeout, in case sometimes an event goes missing, to proceed with the run
> >
stop without getting stuck waiting for the logger.
> 
> yes, that's right, if trigger control and run control are in
the same frontend, you run into this trouble:
> 
> user pushes run stop button
> you get the run stop callback
> you
stop the trigger
> but have to wait for all the data to flush down the pipes all the way to mlogger
> but cannot
wait, must return from the callback otherwise run transition is stuck
> 
> if trigger control and run control are in
different frontends, things are simpler:
> 
> user pushes run stop botton
> trigger control frontend disables the
trigger, returns without waiting for anything
> data frontend (i.e. FGD, TPC), flush all the hardware FIFOs, etc to
MIDAS SYSTEM buffer (trigger is already 
> disabled, there is no new data)
> mlogger flushes SYSTEM buffer to disk
>
run control frontend reports successful run stop to the run database (and whatever else).
> 

What do you mean by
the run control frontend in this case? Usually the run stops are issued from the mhttpd interface, which I thought
meant that mhttpd is in charge of run transitions.

From what I understand, deferred transition means that whichever
frontend registered the deferred transition will take over the run transition. So, if there's no deferred transition
in the first place then this should not be a problem?