TRestRawSignalAnalysisProcess. Redefining meanRate and EventTimeDelay

[jgalan]

This PR is to address the issue raised at rest-for-physics/framework#126. It seems some observables are not thread safe.

Redefining the mean rate calculation using the event id should produce more reliable results. However, this might depend on the electronics producing the good event ordering. I.e. empty events generating additional event ids may derive on overestimated rates.

[nkx111]

In this way the EventTimeDelay is still not precise. It would be AverageEventTimeDelay.

Maybe we shall instead add an option to TRestRawSignalAnalysisProcess, meaning to calculate precisely those two observables. If so, we force single thread to run processes.

[jgalan]

However, it is EventTimeDelay properly calculated? If it is threaded, then the previous entry is not really the previous entry, right?

So, how do we force to run in single thread mode through and option in TRestRawSignalAnalysisProcess?

[nkx111]

So, how do we force to run in single thread mode through and option in TRestRawSignalAnalysisProcess

There is a data member fSingleThreadOnly from TRestEventProcess. If set to true, the whole process chain will run in single thread mode. This should be set in InitFromConfigFile() stage. For example,

void TRestRawSignalAnalysisProcess::InitFromConfigFile() {
    ReadAllParameters();
    if (fCalcMeanRate) {
        fSingleThreadOnly = true;
    }
}

Another possiblity is to move away those observables to another process, for example 'TRestRawRateAnalysisProcess'. We can define this process as a single-thread-only process:

void TRestRawRateAnalysisProcess::Initialize() {
    ...
    
    fSingleThreadOnly = true;
}

There are already some single-thread-only processes, such as TRestRawSignalViewerProcess.

[jgalan]

Yes, second option is probably the best

[jgalan]

I moved to that approach at PR rest-for-physics/framework#130