Optional monitors suggestion

[Martin Nowak via Digitalmars-d]

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.