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.