View mode: basic / threaded / horizontal-split · Log in · Help
November 05, 2007
Re: Signals & Slots
Bill Baxter wrote:
> David B. Held wrote:
>> I know much has been said about this topic over the years, and several 
>> libraries have been written.  Can anyone summarize the state of the 
>> art for S&S in D?  I know there is a std.signals, but I can see that 
>> it is not the end of the story...
> 
> I'd like to know what the current story is too, both in Phobos and 
> Tango.  Mainly I mean the current story with regard to weak references.

Tango does not currently support weak references.  This was a deliberate 
decision on my part because I do not feel that weak references are 
compatible with garbage collection in D.  In a multithreaded program, 
the only way to safely use the callback mechanism built to support the 
weak reference concept is by using lock-free programming (using 
synchronized blocks instead is a sure way to deadlock an application 
when using "stop the world" collections).  However, lock-free 
programming is quite complicated and utterly non-portable, given its 
reliance on specialized knowledge of the target memory model. 
Therefore, I can't rationalize adding a feature that is so prone to 
error and misuse unless it provides an extremely compelling reason for 
its presence.  And I'll admit that I question the point of needing the 
weak reference feature for S&S in the first place.  I feel that doing so 
encourages bad programming style, and frankly, I can't envision a 
programming model that requires it anyway.  But then I'm not a Qt 
person, so perhaps someone could explain the need for this to me?

If it's any consolation, the Tango/Phobos merger will basically require 
that weak reference support be added to the runtime unless Phobos 
decides this feature is no longer necessary.  So my opinion in the 
matter may ultimately be rendered unimportant.  Unfortunately, this will 
complicate the means by which object monitors are overridden in Tango, 
but I don't think there's any way around this.


Sean
November 05, 2007
Re: Signals & Slots
Lars Ivar Igesund wrote:
> Lutger wrote:
>>
>> It's not possible in any of the current implementations (that I'm aware
>> of) to have both managed or tracked connections and thread-safety. I
>> doubt it is possible at all to do in a reasonable efficient manner
>> currently. Perhaps when reference counting will come to D.
> 
> Walter claims that the notifyRegister/Unregister method used by among others
> std.signals _are_ threadsafe. If you are using the same methods, can you
> reproduce deadlocks with sslot? It would be nice to have some actual
> evidence in this matter (either way, although I understand that complete
> thread safety may be impossible to prove for an efficient solution).

I'm fairly sure this is correct, assuming an x86 CPU.  The Phobos S&S 
implementation is lock-free.


Sean
November 05, 2007
Re: Signals & Slots
Lutger wrote:
> Lars Ivar Igesund wrote:
> 
>> It would be nice to have some actual
>> evidence in this matter (either way, although I understand that complete
>> thread safety may be impossible to prove for an efficient solution).
>>
> 
> The following hack resulted in a deadlock on my machine. I also found 
> some access violations, this is perhaps a bug in sslot. A similar 
> program for std.signals also gave deadlocks.

Weird, I'd expect std.signals to work.  But then I just glanced at the 
implementation so perhaps it has a bug or two.  In theory, std.signals 
could work, but the implementation would have to be very carefully done 
(and lock-free as it is now).


Sean
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home