Issue : FD does not print any statistics when it was killed by the OS, scheduler, etc via signals.
It is currently done by print_statistics() in various parts of the search engines, which gets skipped when the search is terminated externally.
More broadly, other classes (e.g. heuristics, evaluators, pruning) can report other useful statistics, if one wish.
Pros: I do not think destructures are *always* called, but they at least have the better language-level guarantee of
being actually called for stack-allocated objects.
It also feels the right place to put the clean-up code that runs at the end of a search engine object lifetime.
Cons: Consing must be discouraged in a destructor and its code requires more care.
Related: out-of-memory handler
I am aware of the issue about signal handling and reentrancy (https://issues.fast-downward.org/issue479) mostly. The C++20 standard (or earlier standards) mandates the following requirement to the signal handler and out-of-memory handlers, as mentioned in here for example https://en.cppreference.com/w/cpp/memory/new/set_new_handler . Throwing bad_alloc() and catching it in main() feels like a much better option than the current implemnetation, since it unwinds the stack and gracefully calls the destructors, which would have the good aforementioned side effect if combined with statistics reporting.
ISO/IEC JTC1 SC22 WG21 N 486 page
17.6.3.3
Type new_handler
[new.handler]
using new_handler = void (*)();
1
The type of a handler function to be called by operator new() or operator new[]() (17.6.2) when
they cannot satisfy a request for additional storage.
2
Required behavior: A new_handler shall perform one of the following:
(2.1)
— make more storage available for allocation and then return;
(2.2)
— throw an exception of type bad_alloc or a class derived from bad_alloc;
(2.3)
— terminate execution of the program without returning to the caller.
|