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