On 5/10/16 1:46 PM, Vladimir Panteleev wrote:
Here is the situation, AIUI:
1. We allow users to provide their own Monitors, which hook into the
synchronized(obj) statement.
2. These monitors' methods are unadorned (no nothrow/@nogc).
3. As a result, synchronized(obj) statements will not compile in
nothrow/@nogc code, because we can't know that the Monitor
implementation doesn't throw / use the GC.
4. As Matthias mentioned, fixing this was attempted before (by making
the Monitor methods `nothrow`). However, this broke code (vibe.d
specifically), as its implementation was actually not `nothrow`:
https://issues.dlang.org/show_bug.cgi?id=11216
This is a problem e.g. in Druntime code, because it currently forces a
lot of code that should be `nothrow` to not be annotated as such, even
when the synchronization objects used use the standard D monitor
implementation, which is actually `nothrow`.
So I guess the way forward here for the Druntime code is to abandon the
synchronized() statement and use locks directly?
Does synchronized(someMutex) go through the same mechanism? Because it
shouldn't, and then we can have the compiler properly interpret what the
nothrow @nogc status is.
I think Monitor.lock/unlock should be nothrow/@nogc. I'm not familiar
with the vibe.d code, but I'd believe that if you need those to throw or
allocate, then you should have to go through another mechanism.
-Steve
