Synchronized object must not be deleted. causes useless error message

[Frits van Bommel]

BCS wrote:
> Frits van Bommel wrote:
>> BCS wrote:
>>> this
>>>
>>> auto o = new Object;
>>> synchronized(o)
>>>     delete o;
>>>
>>> causes a runtime error:
>>>
>>> Assertion failure: 'h->monitor" on line 99 in file 'internal\monitor.c'
>>
>> So what would you prefer to happen?
> 
> Except that I was testing to see what would happen in that case, I'm not 
> sure I would have any clue what was wrong.
> 
> 
> options (in no special order):
> 
> 1> objects that are "locked" can't be deleted.

That may be pretty easy to implement, actually. You'd just need to add 
an extra function to check if the monitor is locked to 
internal/monitor.c, then call that from _d_delclass in internal/gc/gc.d.

> 2> deleting a locked object, unlocks it. :b

Since it's always a bug to delete a locked object (i.e. one that's 
currently in use) it's better to just produce an error message.

> 3> some sane error message at either the delete or unlock
>     Error: can't delete locked object.
>     or
>     Error: can't unlock deleted object.

Yeah, the error message could have been better. I guess Walter didn't 
take into account the fact that someone might be stupid enough to delete 
a locked object when he wrote that code :P.

> problems:
> 
> #1
> 
> thread 1:
>     synchronized(o)
>         while(true){go = true;}
> 
> thread 2:
>     go = false;
>     while(!go){};
>     delete o;    // fail
> 
> #2
> 
> threads 1-n competing on this:
>     synchronized(o)
>     {
>         auto  a = o.getChild();
>         wait();
>         a.foo;    // more than one thread could get this
>     }
> 
> thread 0:
>     delete o;
> 
> #3
>     what should it say?
> 
> 
> Yes, it is a bug, but the error response is not good.

Like I said, the message could be better.

Now that I think about it, maybe it should also be delivered by throwing 
an exception instead of just asserting...
Or maybe not, since that would make it too easy to suppress accidentally 
(there are probably still some people who use catch-all exception 
handlers out there)