Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-11-22 14:39:08

On Wed, 22 Nov 2000 19:41:22 +0200
"Peter Dimov" <pdimov_at_[hidden]> wrote:

> From: "Douglas Gregor" <gregod_at_[hidden]>
> > 3) We have three different sets of semantics for callback copying -
> explicit reference counting (which your implementation uses), shared_ptr
> reference counting (which I use), and cloning (Peter Dimov's function_ptr).
> Cloning is safest (but inefficient), whereas shared_ptr is currently not
> thread-safe and explicit reference counting could easily be made safe. What
> is the goal of the Boost callback library regarding thread safety vs.
> efficiency?
> <
> Note that, as Kevlin Henney already pointed out, there's more to
> thread-safety than the reference counting.
> callback<void> c(F());
> callback<void> c2(c);
> // thread 1
> c();
> // thread 2, at the same time
> c2();
> Even in a single thread, the cloning and counted callbacks are different.
> It's not only a thread-safety vs. efficiency tradeoff.
> We'll have to decide which behavior we need. Is the efficient copy so
> important? Callbacks are rarely copied, in my opinion. However, a reference
> counted callback has the nice property that its copies are exactly
> equivalent even when the pointed-to function object has state; some STL
> algorithms require this.

Perhaps this is a boon to a reference-counted callback. Instead of relying on the callback to order the c() and c2() calls above, supply a functor adapter which handles this. This doesn't solve the non-thread-safety in shared_ptr itself, but I believe William Kempf has that solved already?

> Of course there's always the option of supplying both. :-)
> > 4) Making callback an AdaptableBinaryFunction is a good idea...
> Is it? I've never used the AdaptableBinaryFunction concept. Neither function
> pointers nor lambda/expression.hpp generated function objects are
> AdaptableBinaryFunctions.

Function pointers (and their arguments) can be picked out in function calls, however.

> The concept was useful back at the time when the STL was designed (no
> partial specialization) but we have traits and other techniques available
> now.

Traits don't help function pointers either. Perhaps AdaptableBinaryFunction is a dead concept, but I'd like to see a dominant functor_traits which accomodates all functors before I throw away AdaptableBinaryFunction completely.

        Doug Gregor

Boost list run by bdawes at, gregod at, cpdaniel at, john at