On Thu, 22 May 2014 02:48:16 -0400, Martin Nowak <c...@dawg.eu> wrote:
On Monday, 19 May 2014 at 07:11:41 UTC, Yuriy wrote:
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been set up in
druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count (though that
design had other problems).
I'm not saying your design is wrong, just that we should consider what
to do with these other issues.
My current PR doesn't affect that also. The signals and finalization
callbacks do work as they used to. What changes is just monitors are
looked up in an external hash table, when they are not declared inside
the class, by applying @monitor attr to it. synchronized blocks are
also not affected in the same way.
However, if you're planning to use monitors for reference counting,
such external lookup may become a huge performance issue. But current
reference counts of monitors themselves are not an issue at all.
I'm on my way to DConf now, so we can talk about details there if you
wish.
I don't see why we need to introduce a global hashtable (performance
impact, not pure). We could warn/deprecate/remove synchronizing on
classes without the @monitor attribute.
A possible path is to introduce the change, but put @monitor on Object.
This will allow all current code to compile as-is.
Then users who are concerned about their code being affected would be able
to remove @monitor from Object, recompile druntime and phobos (once we
make it work) and allow people to see how their code breaks without being
left hanging (the shipping compiler would still have @monitor).
Then eventually, we can remove @monitor from Object, and users who still
wish to force @monitor on Object can do so (recompile druntime and phobos
with @monitor added).
-Steve
