Both shared & local classes, method selection

Dicebot via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Aug 29 07:37:42 PDT 2014


On Friday, 29 August 2014 at 14:16:51 UTC, Etienne wrote:
> On 2014-08-29 9:39 AM, Dicebot wrote:
>> based on shared qualified I'd call it a smart ass one and 
>> never accepted
>> it through code review :) Such things really need to be 
>> explicit, magic
>> is worst enemy of multi-threading
>
> The other option is to keep `__gshared ThreadSlot[Thread] 
> gs_signals;` member and add a `NotifierSlot[] m_notifiers;` 
> member, based on a boolean in the constructor `this(bool 
> makeShared = true)`.
>
> I wouldn't really want to make another class in the vibe.d 
> interface and make this one forcefully shared, or should I?

I don't know much about API you are trying to conform to but 
having thread-local and shared cases handled totally differently 
(with 2 different classes) sounds 100% reasonable to me.


More information about the Digitalmars-d-learn mailing list