Re: [boost] New New Callbacks Uploaded

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-22 20:27:44

>In message <20001122120939.62bd5d47.gregod_at_[hidden]>, Douglas Gregor
><gregod_at_[hidden]> writes
>>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?
>
>We can go a number of ways on this. We need to recognise that for non-
>const cases, unless we require physical const-ness for all function
>objects passed, there is absolutely no way that we can make an arbitrary
>function smart pointer for an arbitrary function object thread-safe and
>lightweight.
>
>This means that we have three choices:
>
>(1) Impose this restriction.

In other words the responsibility for making the functor call thread safe
relies on the functor itself. The functor can do this by not having any
mutable state or by using thread synchronization objects.

>(2) Separate out the mutability aspect into a separate class, ie
>function_ptr and const_function_ptr. The former is not reference counted
>and the latter requires deep, physical const-ness but can be reference
>counted.

Or perhaps the body copy semantics can be special cased more intelligently.
Maybe using some sort of traits mechanism. For example, it's pretty silly
to clone a functor wrapping a method call.

>(3) Not implement reference in the function_ptr at all.
>
>IMHO, (3) is now the most reasonable option. If we wish to have
>reference counting of an object, then we can provide it using a smart
>pointer. The only problem with this is that most smart pointers,
>including shared_ptr, are restricted to the narrow view of supporting
>only operator* and operator-> wrt pointer-ness.

Interesting idea, although it seems like the utility of the non-copyable
callback is pretty limited.

  -- Jesse