www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - sslot 0.3 release

reply Lutger <lutger.blijdestijn gmail.com> writes:
I have updated sslot, a signal-slots library.

links:
http://lutger.ifastnet.com/
http://lutger.ifastnet.com/sslot/overview.html

Some of it's features are:
- return values
- can connect functions, delegates, functors, etc.
- signals are iterable
- managed connections


Here is the changelog for this version.

* blocking slots is removed for simplicity
* Object references are not needed anymore to connect managed slots
* Slot implementation is now a 'policy' template
* implemented combiners with mapReduce, see MapSignal
* performance improvements
* fixed defaultHandler bug
* removed dependency on meta.nameof
* fixed support for functor types
* requires dmd 1.10
* backTrace with version=sslotBackTrace
Mar 28 2007
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Lutger, is sslot thread-safe?
Mar 28 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Dejan Lekic wrote:

 Lutger, is sslot thread-safe?


No, not yet. I'm still figuring out what I have to do to make it so.
Mar 28 2007
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Lutger, my suggestion is to do what QT does -
http://doc.trolltech.com/4.2/threads.html#signals-and-slots-across-threads

Kind regards

PS. I would like to see this in Phobos' signal/slot implementation.
Mar 28 2007
next sibling parent reply Witold Baryluk <baryluk mpi.int.pl> writes:
On Wed, 28 Mar 2007 14:10:23 -0400
Dejan Lekic <dejan.lekic gmail.com> wrote:


 PS. I would like to see this in Phobos' signal/slot implementation.


http://www.digitalmars.com/d/phobos/std_signals.html

:)

-- 
Witold Baryluk
Mar 28 2007
parent Witold Baryluk <baryluk mpi.int.pl> writes:
Sorry, i misunderstood your post. So ignore mine.
-- 
Witold Baryluk
Mar 28 2007
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Dejan Lekic wrote:

 Lutger, my suggestion is to do what QT does -
http://doc.trolltech.com/4.2/threads.html#signals-and-slots-across-threads
 
 Kind regards
 
 PS. I would like to see this in Phobos' signal/slot implementation.


Thank you for the link. It is still not clear to me what is necessary, 
the QT s/s mechanism is tightly integrated to the whole framework so not 
seems to be applicable.

What it comes down to looks like a lot of mutexes to me though. I am not 
so familiar with multi-threaded programming, perhaps you can help me 
with these questions:

Would it be preferable to have a thread safety as an option, and if so 
in what way? Versioning or seperate classes?

Do reads from (non-volatile) data need to be synchronized?
Mar 28 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:

 Dejan Lekic wrote:

 Lutger, my suggestion is to do what QT does - 
 http://doc.trolltech.com/4.2/threads.html#signals-and-slots-across-threads 


 Kind regards

 PS. I would like to see this in Phobos' signal/slot implementation.


 
 Thank you for the link. It is still not clear to me what is necessary, 
 the QT s/s mechanism is tightly integrated to the whole framework so not 
 seems to be applicable.
 
 What it comes down to looks like a lot of mutexes to me though. I am not 
 so familiar with multi-threaded programming, perhaps you can help me 
 with these questions:
 
 Would it be preferable to have a thread safety as an option, and if so 
 in what way? Versioning or seperate classes?
 
 Do reads from (non-volatile) data need to be synchronized?


I found the answers to my own questions, but upon reflection there seems 
to be a lot of potential for deadlocks. It will probably take a while 
for me to figure out the details, I don't want to infest sslot with 
subtle bugs.
Mar 29 2007
parent reply Sean Kelly <sean f4.ca> writes:
Lutger wrote:

 Lutger wrote:

 Dejan Lekic wrote:

 Lutger, my suggestion is to do what QT does - 
 http://doc.trolltech.com/4.2/threads.html#signals-and-slots-across-threads 


 Kind regards

 PS. I would like to see this in Phobos' signal/slot implementation.


 Thank you for the link. It is still not clear to me what is necessary, 
 the QT s/s mechanism is tightly integrated to the whole framework so 
 not seems to be applicable.

 What it comes down to looks like a lot of mutexes to me though. I am 
 not so familiar with multi-threaded programming, perhaps you can help 
 me with these questions:

 Would it be preferable to have a thread safety as an option, and if so 
 in what way? Versioning or seperate classes?

 Do reads from (non-volatile) data need to be synchronized?


 
 I found the answers to my own questions, but upon reflection there seems 
 to be a lot of potential for deadlocks. It will probably take a while 
 for me to figure out the details, I don't want to infest sslot with 
 subtle bugs.


There are a few different approaches available, depending on the 
guarantees want to provide.  I think Andrei actually wrote an article on 
this, but I'll be darned if I can find it right now.  One approach would 
be something like this:

void attach( Slot s )
{
     synchronized
     {
         if( !signaling )
         {
             slots ~= s;
             return;
         }
         queue ~= AddRemove( s, true );
     }
}

void detach( Slot s )
{
     synchronized
     {
         if( !signaling )
         {
             slots.remove( s );
             return;
         }
         queue ~= AddRemove( s, false );
     }
}

void signal()
{
     synchronized
     {
         ++signaling;
     }
     foreach( s; slots )
     {
         s();
     }
     synchronized
     {
         if( signaling == 1 )
         {
             foreach( m; queue )
             {
                 if( m.isAdd )
                     slots ~= s;
                 else
                     slots.remove( s );
             }
         }
         --signaling;
     }
}

struct AddRemove
{
     Slot slot;
     bool isAdd;
}

The tradeoff here is twofold: first, the signal mechanism must acquire 
two locks to send a signal, and second, the processing of add/remove 
requests is asynchronous when a signal is being sent.  Still, it only 
uses one lock and behavior is fairly predictable.


Sean
Mar 29 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Sean Kelly wrote:
<snip

 
 The tradeoff here is twofold: first, the signal mechanism must acquire 
 two locks to send a signal, and second, the processing of add/remove 
 requests is asynchronous when a signal is being sent.  Still, it only 
 uses one lock and behavior is fairly predictable.
 
 
 Sean


Thank you very much! I realized a similar scheme is also necessary for 
single-threaded code, since removal *may* happen during signalling if 
the GC is run.

My apologies for this bug. I actually had this solved in some previous 
implementation but it slipped back in again.
Mar 29 2007
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Mr. Kelly, this is more/less what I would like to have in std.signals ... Is
there any chance Mr. Bright will do this? :)
Mar 30 2007
parent Sean Kelly <sean f4.ca> writes:
Dejan Lekic wrote:

 Mr. Kelly, this is more/less what I would like to have in std.signals
 ... Is there any chance Mr. Bright will do this? :)


I think you'll have to ask Mr. Bright :-)


Sean
Mar 30 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lutger wrote:

 I have updated sslot, a signal-slots library.
 
 links:
 http://lutger.ifastnet.com/
 http://lutger.ifastnet.com/sslot/overview.html
 
 Some of it's features are:
 - return values
 - can connect functions, delegates, functors, etc.
 - signals are iterable
 - managed connections
 
 
 Here is the changelog for this version.
 
 * blocking slots is removed for simplicity
 * Object references are not needed anymore to connect managed slots
 * Slot implementation is now a 'policy' template
 * implemented combiners with mapReduce, see MapSignal
 * performance improvements
 * fixed defaultHandler bug
 * removed dependency on meta.nameof
 * fixed support for functor types
 * requires dmd 1.10
 * backTrace with version=sslotBackTrace


Sounds nice.  Just curious -- what is it you require from dmd 1.10?

--bb
Mar 28 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:

 
 Sounds nice.  Just curious -- what is it you require from dmd 1.10?
 
 --bb


dmd 1.10 provides std.gc.capacity, which can tell you if a block of 
memory is allocated by the gc. I use this to check if a delegates comes 
from an object (with the .ptr property), in which case the signals hooks 
a delegate with notifyRegister on the object which is called on 
destruction for auto disconnection.
I should have documented this btw.
Mar 28 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Lutger wrote:

 Bill Baxter wrote:

 Sounds nice.  Just curious -- what is it you require from dmd 1.10?


 
 dmd 1.10 provides std.gc.capacity, which can tell you if a block of 
 memory is allocated by the gc. I use this to check if a delegates comes 
 from an object (with the .ptr property), in which case the signals hooks 
 a delegate with notifyRegister on the object which is called on 
 destruction for auto disconnection.
 I should have documented this btw.


You realize that just because a block of memory is GC-allocated doesn't 
mean it's an Object? It could just as well be a struct, int, dynamic 
array data or whatever.
Mar 28 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
Frits van Bommel wrote:

 Lutger wrote:

 Bill Baxter wrote:

 Sounds nice.  Just curious -- what is it you require from dmd 1.10?


 dmd 1.10 provides std.gc.capacity, which can tell you if a block of 
 memory is allocated by the gc. I use this to check if a delegates 
 comes from an object (with the .ptr property), in which case the 
 signals hooks a delegate with notifyRegister on the object which is 
 called on destruction for auto disconnection.
 I should have documented this btw.


 
 You realize that just because a block of memory is GC-allocated doesn't 
 mean it's an Object? It could just as well be a struct, int, dynamic 
 array data or whatever.


Yes of course. This block comes from the .ptr property of a delegate 
which is already type checked, so there are just a few types left which 
are unsafe to connect. That's why I said I should have documented it, 
kinda stupid to leave this important information out...
Mar 28 2007