assert semantic change proposal

[Sean Kelly via Digitalmars-d]

On Wednesday, 6 August 2014 at 20:22:58 UTC, David Bregman wrote:
> 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?

It seems like this change in treatment of assertion failures 
might require a change in runtime behavior as well.  But I don't 
know exactly what people have in mind.  Also, assuming that a 
change is expected, depending on what the desired effect is, I'm 
not sure I'll know how to do it.


>> 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.

Well, it seems like the underlying idea is to treat assertion 
failures more strongly than we do now.  So changes in how these 
are handled by the runtime might be a side effect of this 
proposal.