Community

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

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
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.
--bb

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.

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

Lars Ivar Igesund wrote:
> Lutger wrote:
...
> 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).
>
Hmmm, I remember Walter saying std.signals isn't thread-safe, maybe I;m
wrong? Sean mentioned the reason the notifyRegister/Unregister methods
aren't implemented in Tango is the potential for deadlocks.
Here is the deadlock scenario as I understand it:
1) delegate A is stored by notifyRegister (as a weak reference that is).
2) Method B gets a lock
3) Concurrently, Object C is being collected, all threads halt
4) As a result of 3, delegate A is invoked and calls method B
5) deadlock
I'll try to make a case where this happens as proof.

Lars Ivar Igesund wrote:
> Lutger wrote:
...
> 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 should have read the docs for std.signals first, it states: "Not safe
for multiple threads operating on the same signals or slots." The thing
is, notifyRegister itself is threadsafe, but when the delegate that it
stores is called all threads are halted so it's really not safe to use
at all in a multithreaded program if you aren't very careful.

Lutger wrote:
> std.signals only accepts member functions.
That is not exactly correct, it accepts delegates. Delegates are a
superset of member functions and nested functions. std.signals is also
thread safe.

Walter Bright wrote:
> Lutger wrote:
>> std.signals only accepts member functions.
>
> That is not exactly correct, it accepts delegates. Delegates are a
> superset of member functions and nested functions. std.signals is also
> thread safe.
Has it been changed then? At least the documentation states:
BUGS:
Slots can only be delegates formed from class objects or interfaces to
class objects. If a delegate to something else is passed to connect(),
such as a struct member function, a nested function or a COM interface,
undefined behavior will result.
Not safe for multiple threads operating on the same signals or slots.
http://www.digitalmars.com/d/1.0/phobos/std_signals.html

Lutger wrote:
> Walter Bright wrote:
>> Lutger wrote:
>>> std.signals only accepts member functions.
>>
>> That is not exactly correct, it accepts delegates. Delegates are a
>> superset of member functions and nested functions. std.signals is also
>> thread safe.
>
> Has it been changed then? At least the documentation states:
>
> BUGS:
> Slots can only be delegates formed from class objects or interfaces to
> class objects. If a delegate to something else is passed to connect(),
> such as a struct member function, a nested function or a COM interface,
> undefined behavior will result.
>
> Not safe for multiple threads operating on the same signals or slots.
>
>
> http://www.digitalmars.com/d/1.0/phobos/std_signals.html
Oops, you're right. My mistake.