See merge request !502

So far the code could try to create a new event even if no slots were available.
This was due to the fact that there was not count of free slots.
The consequences where an exception out of range further down the road as the return code of the event creation was on top not checked properly.
This adds a free slot counter in the white board

See merge request !474

See merge request !466

Allow AthMpEvtLoopMgr to call ConcurrencyFlags::setNumProcs()

See merge request !467

pyRoot will not perform the implict conversion from a string to
a string_ref -- so add a helper which does.

- replace union with boost::variant
- replace call_ template with simpler fwd template
- add compose to compose lambdas

This allows/forces DataSvc and TsDataSvc to avoid temporary std::string
objects.

See merge request !493

See merge request !494

See merge request !482

Credits to Hadrien for spotting that possibility.
Also dropped a couple of dynamic_casts that were simply not useful and moved the waiting list from map to unordered_map (credits to Hadrien again)

See merge request !486

See merge request !481

See merge request !492

See merge request !483

- prefer `optional` over `unique_ptr` to make a nullable type,
  and avoid heap-allocation of RootFileHandler and POSIXFileHandler
- better implementation of `select1st`,`select2nd`
- prefer value-semantics implementation of `get_bit` and `set_bit`

- remove virtual function destructor, qualify as final
- implement binary operator as friend functions
- implement less than using std::tie

- re-use Gaudi::Details::ostream_joiner
- avoid heap allocation
- avoid recursive variadic pack expansion

See merge request !479

See merge request !478

See merge request !452

See merge request !411

See merge request !484

Sebastien Ponce authored 7 years ago and Marco Clemencic committed 7 years ago

In methods promoteTo(Async)Executed, 2 types of "updates" are taking place :
  - a push to the actionQueue for the updates of other algorithms
  - the update of the current algorithm status
The push itself will ultimately trigger the check for the end of the event, that will check whether all states of all algos of the event are ACCEPTED.
In such a case, it will trigger (via a push to m_finishedEvents queue) the move to the next event or the finalization of the job (last event).
Now suppose that the 2 updates are done in the order I gave them and that the second one is delayed (thread unscheduled by OS).
The push will trigger the check for end event. That check will concledu that the event is not over as one algo (current one) is still in SCHEDULED state !
Thus next event will never come and job will never finalize.
So the order has to be update of the current algo first.

Note that this was found the hard way, on stuck processes, so this really happenned.

Sebastien Ponce authored 7 years ago and Marco Clemencic committed 7 years ago

Each algorithm was so far given to tbb in the form of a pair of tbb tasks, linked together.
The first was running the algo while the second dealt with pushing the updae callback to the action queue.
Providing that the run of the Algorithm was already wrapped into a AlgoExecutionTask, there was no reason to not put the callback there and drop the second task.