www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Both shared & local classes, method selection

reply Etienne <etcimon gmail.com> writes:
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?
Aug 29 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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
Aug 29 2014
parent reply Etienne <etcimon gmail.com> writes:
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?
Aug 29 2014
parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 29 2014