On Wednesday, 6 August 2014 at 19:34:48 UTC, Sean Kelly wrote:
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.
Ah, I see. Then I apologize for giving incorrect information. I
am not that familiar with threads in D yet and I assumed
unhandled exceptions worked like C++. But if you already knew the
answer then why were you asking?
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.
I think there is some kind of misunderstanding here, I have not
proposed any new treatment for assertions. Walter's proposal only
affects release mode, so it's not related to exceptions.
