Possible improvements to ActivityRegistry signals

[makortel]

Documenting here my findings while working on #51277

[makortel]

assign core

[cmsbuild]

New categories assigned: core

@Dr15Jones,@makortel,@smuzaffar you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @makortel.

@Dr15Jones, @ftenchini, @makortel, @mandrenguyen, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

Signals to be removed

• PostESModuleRegistration: appears to be redundant compared to ESModuleConstruction
• JobFailure: only called from FWCore/Services/test/servicesJobReport_t.cpp

Edit: Removed in #51626

[makortel]

Adjust {Pre,Post}ESSyncIOV

• Move the signal emit calls to EventSetupsController::eventSetupForInstanceAsync().
• Add another pre-post signal pair to cover the waiting for available concurrent Record instances (post should be emitted after the task is completed, after which the post signal can be called from a different thread than the pre signal).

[makortel]

Signal pairs whose Post is not called if Pre throws an exception

Edit: see #51545 (comment) for an update

It is desired the Post would be called also in these cases

• {Pre,Post}EventSetupModulesConstruction
• {Pre,Post}ModulesAndSourceConstruction
• {Pre,Post}FinishSchedule
• {Pre,Post}PrincipalsCreation
• {Pre,Post}ScheduleConsistencyCheck
• {Pre,Post}EventSetupConfigurationFinalized
• {Pre,Post}ModulesInitializationFinalized
• {Pre,Post}SourceNextTransition
• {Pre,Post}SourceEvent
• {Pre,Post}SourceLumi
• {Pre,Post}SourceRun
• {Pre,Post}SourceProcessBlock
• {Pre,Post}OpenFile
• {Pre,Post}CloseFile
• {Pre,Post}ClearEvent
• {Pre,Post}PathEvent
• {Pre,Post}ESModuleConstruction
• {Pre,Post}ESSyncIOV
• {Pre,Post}ESModulePrefetching
• {Pre,Post}ESModule
• {Pre,Post}ESModuleAcquire
• {Pre,Post}ModuleDestruction
• {Pre,Post}ModuleEventPrefetching
• {Pre,Post}ModuleEvent
• {Pre,Post}ModuleEventAcquire
• {Pre,Post}ModuleTransformPrefetching
• {Pre,Post}ModuleTransform
• {Pre,Post}ModuleTransformAcquiring
• {Pre,Post}ModuleEventDelayedGet
• {Pre,Post}EventReadFromSource when emitted via delayed reader (in provenance reading case the Post is emitted
• {Pre,Post}ModuleStreamPrefetching
• {Pre,Post}ModuleGlobalPrefetching
• {Pre,Post}ModuleWriteProcessBlock
• {Pre,Post}ModuleWriteRun
• {Pre,Post}ModuleWriteLumi
• {Pre,Post}SourceConstruction

In many cases the Post would end up being called also if Pre throws an exception by creating the guard for calling Post before calling Pre (some signals already do that).

Many other cases would be more complicated.

[makortel]

Signal pairs for which the Post is not called if the operation throws an exception

• {Pre,Post}PathEvent: if specific code in edm::Path::finished() throws an exception, the Post signal is not emitted

I can't exclude there would be more. I thought there were, but on a second look didn't find them.

[makortel]

Signal pairs for which the exceptions from Pre are ignored

• {Pre,Post}WriteProcessBlock
• {Pre,Post}GlobalWriteRun
• {Pre,Post}GlobalWriteLumi

I don't know if we'd want to change these.

[makortel]

C++23's std::move_only_function (works at least in GCC 14) and C++26's std::copyable_function (GCC 16) allow the assigned functions to be noexcept. So in principle we could use those to enforce the Post signal actions to not throw.

The edm::signalslot::Signal itself is already move-only, but the copyability of std::function is used in the connections of signals, so a minimal-effort replacement would need the std::copyable_function.

On the other hand, technically making the Post signal actions noexcept means only that if an exception would be thrown, std::terminate() would be called. That is already the likely behavior when Post actions are called from guard object destructors. So the main benefit would be making the noexcept expectation more self-documenting in the Post action function implementations.

[makortel]

Signal pairs whose Post is not called if Pre throws an exception

Update from #51545 (comment). #51625 left the following cases where it is desired the Post would be called also in these cases

• {Pre,Post}SourceEvent
• {Pre,Post}SourceLumi
• {Pre,Post}SourceRun
• {Pre,Post}SourceProcessBlock
• {Pre,Post}OpenFile
• {Pre,Post}CloseFile
• {Pre,Post}ESModulePrefetching
• {Pre,Post}ModuleEventPrefetching
• {Pre,Post}ModuleEvent
• {Pre,Post}ModuleEventAcquire
• {Pre,Post}ModuleTransformPrefetching
• {Pre,Post}ModuleStreamPrefetching
• {Pre,Post}ModuleGlobalPrefetching

Addressing these cases are expected to be at least moderately complicated.