Thread overview
signal slots library
Sep 24, 2006
Lutger
Sep 24, 2006
Kristian
Oct 12, 2006
Bastiaan Veelo
Oct 12, 2006
Bastiaan Veelo
Oct 13, 2006
Lutger
Oct 13, 2006
Bastiaan Veelo
Oct 13, 2006
Lutger
Oct 13, 2006
Josh Stern
September 24, 2006
Finally I have an initial version of my signal slots library finished. You can get it at http://lutger.ifastnet.com/ or view the online documentation there. Hopefully all is in place, this is my first site and encounter with IE hacks...

Comments, critique etc. is most welcome.
September 24, 2006
On Sun, 24 Sep 2006 20:35:54 +0300, Lutger <lutger.blijdestijn@gmail.com> wrote:

> Finally I have an initial version of my signal slots library finished. You can get it at http://lutger.ifastnet.com/ or view the online documentation there. Hopefully all is in place, this is my first site and encounter with IE hacks...
>
> Comments, critique etc. is most welcome.

Thanks Lutger! I quickly glanced at the docs, and looks good. (Maybe this will find its way to Phobos some day, as I think there really should be a sslot lib in it...) :)
October 12, 2006
Hi Lutger,

I once had a project like that, it was a fun exercise.
http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html
http://www.dsource.org/forums/viewforum.php?f=32
http://svn.dsource.org/projects/dcouple/downloads/
I wish that some of the new language features were available back then. My aim was mainly to arrive at an easy and readable API or syntax, because that was a concern in some of the threads in the newsgroup back then. Another objective was the management of connections, so they are cleaned up when senders or receivers are deleted.

I quickly browsed your documentation, but could not find the answer to an important question:

What happens to an object when only connections exist and it is not otherwise referenced anymore? Does it get collected by the garbage collector, and does it disconnect cleanly when it does?

The answer for my implementation is no, unfortunately, but Uwe Salomon got it right. http://www.uwesalomon.de/code/indigo/files/core/cmdtarget-d.html

I also think that there should be a Signals and Slots implementation in the "standard" library, but it should be one that is invisible to the garbage collector, and works well with it!


Best regards,
Bastiaan Veelo.
October 12, 2006
Bastiaan Veelo wrote:
> http://svn.dsource.org/projects/dcouple/downloads/

Pardon for replying to my own message, but it appears that the latest version is still in the trunc, and has not been tarred into downloads yet. See the changelog at the bottom of the documentation. http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html

Bastiaan.
October 13, 2006
Bastiaan Veelo wrote:
> Hi Lutger,
> 
> I once had a project like that, it was a fun exercise.
> http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html
> http://www.dsource.org/forums/viewforum.php?f=32
> http://svn.dsource.org/projects/dcouple/downloads/
> I wish that some of the new language features were available back then. My aim was mainly to arrive at an easy and readable API or syntax, because that was a concern in some of the threads in the newsgroup back then. Another objective was the management of connections, so they are cleaned up when senders or receivers are deleted.
> 
> I quickly browsed your documentation, but could not find the answer to an important question:
> 
> What happens to an object when only connections exist and it is not otherwise referenced anymore? Does it get collected by the garbage collector, and does it disconnect cleanly when it does?
> 
> The answer for my implementation is no, unfortunately, but Uwe Salomon got it right. http://www.uwesalomon.de/code/indigo/files/core/cmdtarget-d.html
> 
> I also think that there should be a Signals and Slots implementation in the "standard" library, but it should be one that is invisible to the garbage collector, and works well with it!
> 
> 
> Best regards,
> Bastiaan Veelo.

Hi, I know about dcouple, I studied it a bit for my first implementation. Nice job there, also on the documentation.

To answer your question honestly I'm not exactly sure if unreferenced objects get garbage collected, but if they get deleted they are safely disconnected:
Instead of storing references to an object in the signal, I took the approach of giving each object which has slots an unique identifier (mixin, no base class needed). This identifier is stored in a AA and reference counted, each managed slot in the signal also know's it's ID, so the signal can check the validity of a slot. This avoids the problem of objects / slots and signals needing to know about each other.
As for garbage collection, I don't know (or forgot) if taking a delegate from an object counts as a reference that keeps the object alive. I would assume so, as it has a pointer to the object. I'll check Uwe Salomon's code for this issue.

Regarding language features, I was very happy with all the improved template support (IFTI!), this made it very easy to support different callable types.

If I find some time and motivation I will update the thing, I'd like to do blocking and grouping slots.
October 13, 2006
> To answer your question honestly I'm not exactly sure if unreferenced objects get garbage collected, but if they get deleted they are safely disconnected:

OK, that is enough for C++ (Qt) style programming where the programmer has to take care of deletion. However, in D it would be really nice to let the garbage collector do that.

> Instead of storing references to an object in the signal, I took the approach of giving each object which has slots an unique identifier (mixin, no base class needed). This identifier is stored in a AA and reference counted, each managed slot in the signal also know's it's ID, so the signal can check the validity of a slot.

So each time a signal is sent to a slot, it searches the AA to check whether the object is still alive? That seems a bit of an unnecessary overhead.

> This avoids the problem of objects / slots and signals needing to know about each other.

Is it a problem?

> As for garbage collection, I don't know (or forgot) if taking a delegate from an object counts as a reference that keeps the object alive. I would assume so, as it has a pointer to the object.

Correct. The concept of weak pointers has been proposed to the newsgroup a long time ago, which would do as you hoped they did.

> I'll check Uwe Salomon's code for this issue.

He uses malloc and free, if I remember well.


Have fun!

Bastiaan.
October 13, 2006
Bastiaan Veelo wrote:
<snip>
>> Instead of storing references to an object in the signal, I took the approach of giving each object which has slots an unique identifier (mixin, no base class needed). This identifier is stored in a AA and reference counted, each managed slot in the signal also know's it's ID, so the signal can check the validity of a slot.
> 
> So each time a signal is sent to a slot, it searches the AA to check whether the object is still alive? That seems a bit of an unnecessary overhead.

Indeed it is, but only for managed delegates. AA lookup is reasonably fast though. This also makes it safe to delete a slot while emitting a signal.

>> This avoids the problem of objects / slots and signals needing to know about each other.
> 
> Is it a problem?

Well not really but you have to make the object also be aware of the signal to let it 'unregister' itself, so there will be a cyclic reference and I found it gets a little messy this way. But yes, my implementation didn't really solve that problem:

>> As for garbage collection, I don't know (or forgot) if taking a delegate from an object counts as a reference that keeps the object alive. I would assume so, as it has a pointer to the object.
> 
> Correct. The concept of weak pointers has been proposed to the newsgroup a long time ago, which would do as you hoped they did.
> 
>> I'll check Uwe Salomon's code for this issue.
> 
> He uses malloc and free, if I remember well.

I remember that now, a weak reference is what you need, this also came up in the recent signal-slots thread. Didn't think of malloc when I implemented it. I should change my implementation to make use of that.

> Have fun!
>
> Bastiaan.

Thanks, I've never done much low level stuff like casting malloc'ed voids* even in C++, sounds like good fun...
October 13, 2006
On Fri, 13 Oct 2006 16:32:08 +0200, Bastiaan Veelo wrote:

>> To answer your question honestly I'm not exactly sure if unreferenced objects get garbage collected, but if they get deleted they are safely disconnected:
> 
> OK, that is enough for C++ (Qt) style programming where the programmer has to take care of deletion. However, in D it would be really nice to let the garbage collector do that.

It seems like what is really needed is the ability to dynamically associate some type of callback list with finalization of objects.  If there was a way to set a bit flag in the bookkeeping code for an object, then the overhead of this when it is not used would be just checking whether the flag is set.  If it is, there would be an AA lookup on the object address to get the callback list.  Disconnecting signal/slot bindings could be just one example of a callback.   Another example where this would be really useful is for mixing GC and non GC'd code.