Is this truly UB (anything can go wrong, invalid program according to the standard, not just to the programmer's own rules) or a detected bug?   In theory the error could be localized, if either a) it (the nearly deadlock) of a specific mutex is a possible state, with a clear way to recover. = works as designed. b) Subsystems of the process are well separated and the other parts can gracefully shutdown -> e.g. clear interfaces between threads; then why not use separate processes?   -----Ursprüngliche Nachricht----- Von:Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 07.06.2026 00:53 Betreff:Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate An:std-proposals_at_[hidden]; CC:Rainer Deyke <rainerd_at_[hidden]>; On 6/6/26 20:03, Frederick Virchanza Gotham via Std-Proposals wrote: >      "If a mutex fails to lock, the entire process is fried" I don't think that's necessarily the case, although the C++ standard is spectacularly unhelpful about what situations can cause a lock operation to fail and what the resulting std::error_code would look like.  In some cases (where the failure to lock is actually considered likely), it may be possible to fall back to a single threaded code path.  In others, at least an exception gives the process the opportunity to clean up after itself, i.e. delete its temporary files, flush its log files, and properly close its network connections. (The only specifically documented case where an exception could be thrown, on the other hand, truly is unrecoverable.  If locking would deadlock, then the program has already entered undefined behavior and no recovery is possible.) -- Rainer Deyke - rainerd_at_[hidden] -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals