Digital Mars - digitalmars.D - Signals & Slots for Walter

↑ ↓ ← → Andy Friesen <andy ikagames.com> writes:

Norbert Nemec wrote:

 Dr.Dizel wrote:
 
 
Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed
of it. And now you cannot say what you are don't understand it at all. :)


 
 Before rolling up that topic again: I have a pretty good feeling that mixins
 will give us everything we need for signals/slots. Actually trying to do it
 is left as a homework for those interested...


Not really, but it does make implementing them a bit less copy/paste-y.

Unless there's some wrinkle to this that I'm not aware of (I think of 
signals and slots in a C#ish context), they've been easily possible 
within D for eons now.

http://andy.tadan.us/d/listener.d

  -- andy

May 18 2004

↑ ↓ ← → "Achilleas Margaritis" <axilmar b-online.gr> writes:

"Dr.Dizel" <Dr.Dizel_member pathlink.com> wrote in message
news:c8ci8n$2v40$1 digitaldaemon.com...
 Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a seed


 it. And now you cannot say what you are don't understand it at all. :)


What you are all missing is that the signals and slots mechanism has a major
difference than the observable/observer mechanism: in Trolltech's signals
and slots, an object's slots are automatically destroyed when the object is
destroyed.

This little detail makes it necessary for signals and slots to be
implemented as part of the language, and not with templates. Slots must
contain *weak* references to objects, and these references must not be
checked by the garbage collector.

May 18 2004

↑ ↓ ← → Norbert Nemec <Norbert.Nemec gmx.de> writes:

Achilleas Margaritis wrote:

 
 "Dr.Dizel" <Dr.Dizel_member pathlink.com> wrote in message
 news:c8ci8n$2v40$1 digitaldaemon.com...
 Walter, here (http://doc.trolltech.com/3.1/signalsandslots.html) is a
 seed


 it. And now you cannot say what you are don't understand it at all. :)


 What you are all missing is that the signals and slots mechanism has a
 major difference than the observable/observer mechanism: in Trolltech's
 signals and slots, an object's slots are automatically destroyed when the
 object is destroyed.
 
 This little detail makes it necessary for signals and slots to be
 implemented as part of the language, and not with templates. Slots must
 contain *weak* references to objects, and these references must not be
 checked by the garbage collector.


May it be, that this can be split up in two solvable cases:

* When you demand connections to be cut automatically when the receiver is
deleted, you are obviously talking about objects that are not garbage
collected but actively deleted. Therefore, the topic of weak references is
not important.

* When, on the other hand, you do not actively delete the objects you are
working with, then automatic cutting of connections is not an issue.
Therefore, the receiver does not need to keep a reference to the sender.
The reference from the sender to the receiver should not be a weak
reference anyway (An object that can receive messages obviously is not
garbage.)

In neither case you need weak references. Everything else should be possible
in D as it is.

Looking at these two cases, you only need to consider for every class that
implements slots whether it should be manually deleted or garbage
collected. Depending on this, it would either get intelligent (i.e.
auto-disconnecting) or dumb slots (i.e. plain member functions)

May 18 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Norbert Nemec wrote:
 May it be, that this can be split up in two solvable cases:
 
 * When you demand connections to be cut automatically when the receiver is
 deleted, you are obviously talking about objects that are not garbage
 collected but actively deleted. Therefore, the topic of weak references is
 not important.
 
 * When, on the other hand, you do not actively delete the objects you are
 working with, then automatic cutting of connections is not an issue.
 Therefore, the receiver does not need to keep a reference to the sender.
 The reference from the sender to the receiver should not be a weak
 reference anyway (An object that can receive messages obviously is not
 garbage.)
 
 In neither case you need weak references. Everything else should be possible
 in D as it is.
 
 Looking at these two cases, you only need to consider for every class that
 implements slots whether it should be manually deleted or garbage
 collected. Depending on this, it would either get intelligent (i.e.
 auto-disconnecting) or dumb slots (i.e. plain member functions)


I, too, thought this, but especially in the case of GUIs, I no longer 
think that this is the case.  Consider the case of a GUI which is 
viewing a certain document.  Assume for the moment that there are two 
windows viewing the same document, perhaps a "normal" view and a "zoom" 
view.

In the signals & slots architecture, then, there is a signal associated 
with the document which is emitted when the data in the document 
changes.  There are slots in both window objects, which receive the signal.

Now, what happens when one of the windows is closed?  If each window is 
a simple object, then you can explicitly delete the object and 
explicitly disconnect the signals in the destructor.  But that becomes 
very inelegant when the window is a compound object.  The Zoom window, 
for instance, might actually look like this:

class ZoomWindow : FrameWindow {
   MenuBar menu;
   Graphics displayArea;
...
}

Let's assume for the moment that MenuBar and Graphics are both child 
classes of Window, because, at the low-level, they are windows in the 
GUI toolkit being used.

Presumably, the DocumentChanged signal is not actually connected to the 
ZoomWindow; it is connected to the Graphics object.  So, if we are to 
explicitly disconnect the signal, then we must explicitly delete the 
Graphics object as well as the ZoomWindow!  We've now introduced a rat's 
nest of recursive delete's, and have moved away from D's standard gc 
mechanism.

I used to be doubtful of the utility of weak references, but I'm 
starting to become convinced that they are very useful and should be 
implemented.

May 18 2004

↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:

Setting the details of the example aside, it seems like there are going to be a
lot of cases where an object in a GC system has multiple connections which
should not necessarily preserve it.  Solving this will require a more direct
approach.  You can create a widget management system that handles deletion by
tracking all the connections and broadcasting messages as needed.


A sophisticated version would know all the parts that connect to X via a
multimap of some kind.  The simple, but O(N), solution is to just send a message
to everyone everywhere, of the form "Object with serial # 10133 is going away",
and they can drop any pointers to it after finishing any ongoing transactions.
After the message is delivered, the table-of-objects would remove its own
reference.


A much more basic technique is a central hash table of objects - regular users
only have a serial number, but have to handle non-existence cases.

If you can't handle the non-existence case in a particular object, then it needs
a real reference.  This will actually be true a lot, usually when doing "real
operations" on objects, so get a reference to each object at the beginning and
handle the non-exist before committing to a transaction.  That way if the table
entry is cleared you are covered.

This problem can be really thorny in distributed systems (particularly where
performance is an issue - I've seen distributed systems written partly in
assembler that used only refcounts... "dont get out of the boat").  It may be
better to solve the problem explicitly in the design, rather than trying to
create a cyclical reference graph with "automatic fall apart".

Kevin

May 18 2004

↑ ↓ ← → Norbert Nemec <Norbert.Nemec gmx.de> writes:

This whole example still boils down to a design issue of the GUI library.

Widgets are resources, similar to open files, network connections etc. The
concept of garbage collection does not really work well for this kind of
object.

Plain objects only take up space on the heap. If a plain object is not
referenced any more, all it does is to take up space on the heap. It does
not really matter when that space is released, so we can forget about it
and leave it to the GC to collect it whenever it needs space.

Resource objects on the other hand do not only take up space but, as the
name sais, also hold a resource. You always should close a resource object
manually after use. Maybe it is this act of "closing" that we should focus
on, no matter whether closing and deleting of the object fall together or
not. Automatic signal disconnection for widgets should happen at *closing*
time.

GUI objects and Resource objects in general always have to "belong" so
someone. Some object has to take care of closing them after use. This is
unlike plain objects that are just referenced from many places and simply
die when the last reference is cut. If a window containing several widgets
is closed, of course, it has to recursively close all the children. A GUI
library may do that automatically.

And for objects that own neither resources nor any resource objects? These
do not need to be closed explicitely. They will just exist as long as they
are referenced and drop dead once the last reference is cut. An incoming
connection, of course, is just a plain reference in this respect. If there
is the chance that the object might get signaled, it obviously still can
react and therefore, it is not dead and should not be collected.

Weak references, therefore, are not linked to the question of signals and
slots. They may be useful in many contexts, but they certainly are not
*necessary* for signals/slots in any special way.


Russ Lewis wrote:

 Norbert Nemec wrote:
 May it be, that this can be split up in two solvable cases:
 
 * When you demand connections to be cut automatically when the receiver
 is deleted, you are obviously talking about objects that are not garbage
 collected but actively deleted. Therefore, the topic of weak references
 is not important.
 
 * When, on the other hand, you do not actively delete the objects you are
 working with, then automatic cutting of connections is not an issue.
 Therefore, the receiver does not need to keep a reference to the sender.
 The reference from the sender to the receiver should not be a weak
 reference anyway (An object that can receive messages obviously is not
 garbage.)
 
 In neither case you need weak references. Everything else should be
 possible in D as it is.
 
 Looking at these two cases, you only need to consider for every class
 that implements slots whether it should be manually deleted or garbage
 collected. Depending on this, it would either get intelligent (i.e.
 auto-disconnecting) or dumb slots (i.e. plain member functions)


 I, too, thought this, but especially in the case of GUIs, I no longer
 think that this is the case.  Consider the case of a GUI which is
 viewing a certain document.  Assume for the moment that there are two
 windows viewing the same document, perhaps a "normal" view and a "zoom"
 view.
 
 In the signals & slots architecture, then, there is a signal associated
 with the document which is emitted when the data in the document
 changes.  There are slots in both window objects, which receive the
 signal.
 
 Now, what happens when one of the windows is closed?  If each window is
 a simple object, then you can explicitly delete the object and
 explicitly disconnect the signals in the destructor.  But that becomes
 very inelegant when the window is a compound object.  The Zoom window,
 for instance, might actually look like this:
 
 class ZoomWindow : FrameWindow {
    MenuBar menu;
    Graphics displayArea;
 ...
 }
 
 Let's assume for the moment that MenuBar and Graphics are both child
 classes of Window, because, at the low-level, they are windows in the
 GUI toolkit being used.
 
 Presumably, the DocumentChanged signal is not actually connected to the
 ZoomWindow; it is connected to the Graphics object.  So, if we are to
 explicitly disconnect the signal, then we must explicitly delete the
 Graphics object as well as the ZoomWindow!  We've now introduced a rat's
 nest of recursive delete's, and have moved away from D's standard gc
 mechanism.
 
 I used to be doubtful of the utility of weak references, but I'm
 starting to become convinced that they are very useful and should be
 implemented.

May 18 2004