Comment #0 by verylonglogin.reg — 2013-10-10T06:09:20Z
Currently this code fails to compile because `_d_criticalenter` and `_d_criticalexit` are not `nothrow`:
---
void f() nothrow
{ synchronized { } }
---
This is because user supplied monitor can throw as `lock`/`unlock` methods of `Object.Monitor` are not `nothrow`.
Dependent druntime functions like `rt_attachDisposeEvent` and `rt_detachDisposeEvent` are thus not `nothrow` too.
The proposal is to mark user supplied monitor `lock`/`unlock` methods also `nothrow`. In the case it will be rejected documentation note about the fact synchronized statement is not `nothrow` should be added.
Comment #1 by verylonglogin.reg — 2013-10-10T06:14:31Z
Also in the case in the description are there any possibilities to supply a user monitor? If not, this subcase is clearly a "rejects-valid" bug.
Comment #2 by code — 2014-10-01T08:18:28Z
I'm in favor of doing this. Is there a migration path for requiring nothrow on the Monitor Interface without breaking code?
*** Issue 16009 has been marked as a duplicate of this issue. ***
Comment #10 by default_357-line — 2018-02-23T16:14:19Z
Still an issue in 2018.
Comment #11 by default_357-line — 2018-02-23T16:19:53Z
Istm a possible approach would be:
* Define SimpleMonitor : Monitor with nothrow
* change DMD to use nothrow when locking SimpleMonitors
* subclass druntime's Mutex with SimpleMutex : Mutex, SimpleMonitor
* use SimpleMutex as the mutex implementation for class monitors
Then synchronized(this) should be nothrow without breaking existing code that depends on Mutex/Monitor. It would only break if you were assigning to _monitor, and that's easily fixed by using a separate member.
I don't know how to implement this on the DMD side though.
Comment #12 by robert.schadek — 2024-12-07T13:32:57Z