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?

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.

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.

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.

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.

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.

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...