Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Signal&slot objections.

Moderators: kris

Posted: 05/16/07 12:51:35

At the begining - the question about current signal&slot mechanisms in Tango.

Let say I create two objects - emiter and receiver. Then I connect signal in emiter with some method in receiver. Then I "delete receiver;". Is "emiter.sig();" safe now?

From looking at the sources I've got an impression that it is not, because there is no mechanisms to validate existance of object which method signal is about to trigger, nor there is no mechanism to unregister slots on deletion. Method will be called with invalid "this" pointer.

If above statment is untrue and I'm mistaken please forgive me and don't read anything below because it is invalid. But if it is true - read on. On #d.tango larsivi adviced me to elaborate a little onto this topic. :)

I'm taking my experiences Qt's signal & slots. The particular usefulness of it was to connect two (or more) objects which knows nothing about themselfs so that they cannot clean up what was registered in destuctor. In fact most of the time the owner is connecting pair of it's children to create some interaction and then just forgets about that fact unable to unregister anything. That is why there is Slot abstraction and signals cannot be connected to just anything callable like now in Tango, insted it must be "wrapped" in Slot. Slot is what rembembers where function is registered and unregisters it when needed (on destruction).

Is this planned to be added to into Tangos signal&slots?

Author Message

Posted: 05/21/07 20:42:08

How would such a Slot class be implemented, given the current Signal code? I don't have any experience with Qt, so this isn't a scenario that's familiar to me. For what it's worth, the weak pointer and auto-removal functionality was omitted because it could cause an app to deadlock if a Slot id destroyed by the GC. If a signal is firing when a GC cycle is initiated, the Signal thread will be stopped while holding the Signal mutex. Any Slot cleaned up by the GC would try to acquire this mutex to remove itself from the list...

I suppose one alternative would be to only support auto-removal when the Slot is explicitly deleted, and possibly to use a proxy object to avoid building all the notifyRegister functionality into Object (which is messy and doesn't interact well with some other functionality that's been added for Tango), but if an Object really isn't supposed to know that it's being used as a Slot then this suggests that it should work exactly the same as if it weren't a Slot, which suggests that it should be able to go out of scope and be collected by the GC (ie. that Signals should go back to using weak pointers).

Can you suggest an alternative? I realize that the Signal implementation right now is really just a list and a foreach loop, but in my use of this design pattern in the past I've never had any need for the sort of functionality you describe, and I'm having trouble understanding its application.

Posted: 05/22/07 23:40:27 -- Modified: 05/22/07 23:42:59 by

The rationale for such managed connections is that one can seperate the code where connections happen from the code where objects get released. For example in a gui application where a lot of connections are made and objects removed, it can be convenient to decouple these responsibilities. Then there is no need to manually pair connect and disconnect calls, reducing possibly error-prone bookkeeping.

If I am right in that this is the main benefit, a design where one could disconnect all signal connections from a slot without a handle to these signals would suffice as a compromise. This still gives the benefit of not having to track all connections manually. One would only have to remember that some object is possibly used as a slot, and disconnect it from *all* signals, but specific signal handles are not required. I haven't thought about how such an implementation would look like, but this might make it easier?