On Sunday 11 February 2007 05:58 pm, Timmo Stange wrote:
I didn't really follow exactly why you decided to drop Group and GroupCompare. I was able to implement support for them pretty trivially in thread_safe_signal (see thread_safe_signals/detail/slot_groups.hpp and the connect() functions in thread_safe_signals/detail/signal_template.hpp).
As for your solution: If I understand it correctly, your signal does not support the full ordering of the original version. You can establish an order (through at_back/at_front) within the groups and for the ungrouped slots in one signal. The standard containers don't support that notion. You'd need a (meta-)key with an infinite value range to support at_back/at_front in a std::map.
No, it does. There is no std::map, I don't rely on the container at all for ordering. I did try a std::multimap initially, before discovering that their "insert with hint" is not sufficient to maintain ordering within a group. The slot list is just a std::list and I decide the proper place to put each new connection when inserting into the list.
However, you should be able to get concurrent signal invocation even with a single mutex once boost supports a recursive_read_write_mutex, right?
Yes, that would be possible at the expense of copying the combiner for the invocation, which is acceptable and parameterizable through the ThreadingModel anyway.
I copy a shared_ptr to the combiner in the invocation, so a new full copy only gets made in set_combiner(). -- Frank