Optional monitors suggestion

Martin Nowak via Digitalmars-d digitalmars-d at puremagic.com
Wed May 21 23:48:16 PDT 2014


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.


More information about the Digitalmars-d mailing list