On Wednesday, 6 August 2014 at 18:15:41 UTC, David Bregman wrote:
On Wednesday, 6 August 2014 at 17:18:19 UTC, Sean Kelly wrote:
So from a functional perspective, assuming this is a
multithreaded app, what should the procedure be when an
AssertError is thrown in some thread?
afaik, AssertError works the same as any other exception. If it
reaches the top without being handled, then the entire app will
be terminated including all the other threads.
Except that's not really how unhandled exceptions are treated in
threads. They're stored by the thread and (optionally) re-thrown
in the context of whatever thread calls join, if any thread calls
join at all. The assumption at the time was that the joining
thread cared about the state of the thread being joined and so
re-throwing the exception was a way to communicate the error to
the most interested party.
So if the main thread joins a thread that terminated with an
unhandled AssertError, the error will be re-thrown in the context
of the main thread, which will in turn join all remaining running
threads and wait for them to complete. This is the same behavior
as if an AssertError is generated during normal processing of the
main thread. But in neither case is the application forcibly
terminated when an assertion failure occurs.
So again, my question is twofold: what *should* happen, given
this new treatment for assertions, and then *how* will we
accomplish this? A multithreaded process is really pretty much
equivalent to a bunch of standalone processes with shared memory.
There is no facility for forcing a clean termination of another
thread. The best I can think of would be to assume that
std.concurrency is being used for multithreading and sort things
out similar to the existing LinkTerminated signaling, but looking
for a reasonable solution within Druntime would be tricky.
