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