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.