Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-23 09:39:08

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <v03110703b6421d10642f@[153.32.222.4]>, Jesse Jones
> <jejones_at_a...> writes
> >>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.
> 
> Exactly. It would be part and parcel of the function object
> requirements.

Except that the requirements don't always exist.  That's the nasty 
part about thread safety.  It costs in terms of memory and 
performance.  This cost can be prohibitive for a wide range of uses 
(not all programs even have multiple threads, and even those that do 
have large areas of code that are logically protected from thread 
safety issues because they don't share data).  So, I don't know if I 
like this approach.

> >>(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.
> 
> I presume that the default would have to err on the side of safety.
> Although is no need to copy member or non-member function wrappers,
> there is an issue over the amount of specialisation involved to 
meet the
> expectations, eg pretty much all function object types in the 
standard
> and I guess many parts of the Lambda library. How much coupling do 
we
> want? I think that the amount of configuration involved would put 
me off
> this solution.

You need to strive for no coupling, else you infringe on functor 
libraries of the past and future.
 
> >>(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.
> 
> There's no restriction of the copyability. If you want reference
> counting, and you want to manage the risks of inter-thread sharing, 
you
> would write something like
> 
>         shared_ptr< function_ptr<void> > s(new_function_ptr(f));
>         ...
>         s();

Except that shared_ptr doesn't have an operator() ;).  I don't think 
you can add it, either, as you don't know how many parameters the 
wrapped functor will take.  Not a big deal, though, since (*s)(); 
will work.

Bill Kempf