Re: [Boost-users] [signals] thread_safe_signals feature-complete

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-17 14:59:19

On Saturday 17 February 2007 01:56 pm, Timmo Stange wrote:
> In the slot_call_iterator template I don't understand why
> you call lockNextCallable in dereference() and call it
> twice (instead of just once after incrementing the
> iterator) in increment(). That function may advance the
> iterator, which can do you no good in dereference() and
> is unnecessary there, as far as I can tell.

It's to compensate for the fact that it is not called in the constructor, 
which I originally tried.  If it's not called before the first 
dereference, then you might try to execute an invalid slot.  If it's not 
called before the first increment, then you might not increment past the 
first slot.  I got rid of the call in the constructor because it killed 
concurrent invocation, due to the iterators still in scope in operator() 
holding locks to the first slot.  However, since I optimized it to only 
create temporary iterators when passing them to the combiner, I could 
probably just put the call back into the constructor.

> It also doesn't seem like the slot_call_iterator skips
> disconnected slots.

It does, blocked returns true for disconnected slots.  It passes all the 
test programs (at least it did the last time I tried them).  I 
occasionally get infinite loops and segfaults in random_signal_system.cpp, 
but that is due to some bug in the test code (the same thing happens with 
boost.signals 1.32).

-- 
Frank