assert semantic change proposal

[Sean Kelly via Digitalmars-d]

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.