assert semantic change proposal

[David Bregman via Digitalmars-d]

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.