DPL Analysis: preliminary work for multiple process() functions - #6019

@ktf @jgrosseo this is a working example of multiple process functions in an analysis task. Process functions can have different signatures, only the selected functions will affect what the task subscribes to. The only caveat currently is that filters are applied for each of the process functions, so I'll have to add some caching behavior for selections.

Excellent! This was very fast. I am in favour of merging this.

Next, we can look at how to make this more than trivially configurable.

For instance:
adaptAnalysisTask<MultipleProcessExample>(cfgc, ProcessesOptional{&MultipleProcessExample::processRec, cfgc.options().get<bool>("doRec"), &MultipleProcessExample::processGen, cfgc.options().get<bool>("doGen"), &MultipleProcessExample::processResolution}, cfgc.options().get<bool>("doResolution"))};

It still needs filter caching, otherwise it would be a performance problem. Related to that is the question whether we also want to have optionally different filters for different processes.

Configuration like that is not trivial, we'll have to discuss what we can do.

why performance problem? doing the filters twice is what would happen right now with two devices, no?

It seems adding proper caching also requires also changing how Filtered behaves, currently it always has an internal copy of a selection vector. Since this is already functional I'm marking it ready for review and caching will be the next improvement for this.

@aalkin I think the filter caching should anyway go beyond the same process. Our idea is to pull this into a common process if there are several tasks (in independent processes) having the same filter, right?

@aalkin I think the filter caching should anyway go beyond the same process. Our idea is to pull this into a common process if there are several tasks (in independent processes) having the same filter, right?

At a baseline we need to cache the filter result (row list) in a task, so that it can be supplied to each process() in the task that requires same-ish argument. For example if all process() functions require some sort of join based on aod::Collisions we only need to create the row list once and re-use it each time we create the Filtered argument for a given process(). I already have an idea on how to implement it, but I need to invent a good static way to determine which process() arguments are equivalent in terms of required filters so I can avoid runtime checks.