Hey,

I'm trying to build a driver for my native event implementation in vibe (https://github.com/etcimon/event.d/ and https://github.com/etcimon/vibe.d/blob/native-events/source/vibe/core/drivers/native.d)

I currently have 2 ways of signaling an event loop to wake up, the AsyncNotifier (event loop is local, this is lock-less) and the AsyncSignal (event loop in another thread, this one locks).

I must modify LibevManualEvent and rename it to NativeManualEvent in the native.d file, this class inherits ManualEvent. What I'd like to do is be able to have :

shared NativeManualEvent m_signal; // uses AsyncSignal as implementation
NativeManualEvent m_notifier; // uses AsyncNotifier as implementation

I'd like to be able to do `static if (is(typeof(this) == shared))` to implement these two versions differently, but I'm not sure if this event works or if it is the best way. Ideally, I'd like to have the same class redefined with and without `shared`. e.g. final shared class NativeManualEvent; final class NativeManualEvent; so the compiler can choose the right one.

Is there a defined way of dealing with this problem?

http://dpaste.dzfl.pl/2a17662ce5b0

Doing completely separate implementation based on sharedness may be a bit more tricky. std.typecons.Proxy comes to my mind immediately but it does not allow proxying two objects with same method names.

At the same time it does not sound like a good idea to me. If I'd encounter code that magically picks totally different implementation 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

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?

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.