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.

Reply via email to