Signals & Slots

[Lars Ivar Igesund]

Lutger 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...
>> 
>> Dave
> 
> Besides std.signals, there is a S&S implementation in Tango, one in
> Luigi by Bill Baxter and one written by myself (sslot).
> 
> There are mostly two differences between these implementations:
> thread-safety and the types of slots that are allowed to connect.
> The tango implementation is thread-safe, at the cost of being unable to
> 'track' connections. sslot has a thread-safe implementation which
> frankly stinks, because it's not really thread-safe at all (deadlock
> possibility in some - documented - circumstances).
> The ones in Luigi and sslot are the most generic, and tango's signals
> can also accept functions. std.signals only accepts member functions.
> 
> 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).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango