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

Lutger, is sslot thread-safe?

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.

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.

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

Sorry, i misunderstood your post. So ignore mine.
-- 
Witold Baryluk

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

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.

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?

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.