Re: [Boost-users] [signals] sandbox version status

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-11 18:18:13

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