Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-30 15:54:19

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <903oa0+7kdd_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> >A lot of function objects must carry 
> >> >state around with them, state which is modified with each 
> >invocation 
> >> >of operator().  
> >> 
> >> Some, but certainly not the major part.
> >
> >That's debatable, and frankly depends on the application.
> 
> I am talking across applications. I can hand on heart say that I 
would
> be surprised if you believed that the main use for function objects 
was
> to carry modifiable state. They are a use, but I think relatively 
few
> people believe they are the main use.

Sorry, but "main part" and "a major part" are quite different 
concepts (you did say "the major part" which could be equivalent 
to "main part" but that argument is pointless so I assumed you 
meant "a major part").  I don't care if 75% of the usage fits your 
other categories, if 25% fits the third category it MUST be addressed 
accordingly in the implementation.  And frankly, I think we've made a 
case that for many of us it's at least close to this, if not 
exceeding it.  For STL algorithm usage I might reduce this to your 
point of view, but, frankly, the concept being discussed here is 
needed precisely because we're using it in places and for uses other 
than STL algorithms.  Closures are going to be a very big usage for 
this concept, and closures are nearly always modified state function 
objects.
 
> >> Function objects fall into three
> >> categories wrt state:
> >> 
> >> (1) Stateless, eg functions, many of the function object types 
in 
> >the
> >> standard, many predicates, many transformations.
> >
> >Functions aren't necessarily stateless.  A static or global 
variable 
> >can be used to maintain state (though difficult to use in MT apps).
> 
> This was addressed in the other email. What is meant here is pure
> functions. Sorry, I should have been more explicit.
> 
> >> (2) Stateful but with fixed state, eg many bound function 
objects, 
> >many
> >> of the other function object types in the library, many 
predicates, 
> >many
> >> transformations.
> >> 
> >> (3) Stateful but with changeable state, eg RNGs, accumulators.
> >> 
> >> In my experience, category (1) and (2) cover most of the uses, 
eg 
> >the
> >> callback examples cited, predicates, etc would fall into these
> >> categories, hence no need for synchronisation. Category (3) is 
the
> >> minority category, IME, and it is only category (3) that 
definitely
> >> requires synchronisation.
> >
> >No matter what you experience, (3) is a large enough category to 
need 
> >addressing.  For some applications it's a very large category, 
maybe 
> >even the only category.  You can't dismiss it as a corner case 
just 
> >because of your experience.
> 
> Sorry, I didn't realise that my emails were so open to 
misinterpretation
> so frequently! From what I can tell, I think much of our discussion 
has
> come from this :-}

Well, I'll take at least some blame here.  When I read posts in 
discussions like this I often have problems seeing other points of 
view unless they are explicitly stated as different view points.  
Instead I see them as criticisms of the view that I hold (which isn't 
bad, it just means I misinterpret things when the track is changed 
like this).
 
> Let me summarise: (1) and (2) cover most cases, (3) is significant 
but a
> minority. This means that although one could make a case for 
requiring
> immutability based on majority rule, it would be too restrictive 
because
> it would foreclose, unreasonably, the possible use of (3). This is 
what
> I meant in an earlier posting as being too restrictive, and hence 
why I
> felt it an unreasonable design.

And now I'm lost.  Too many messages in between these posts, 
probably.  The possible use of (3) causes what to be an unreasonable 
design how?  It _seems_ like you're agreeing with what I've been 
trying to get across here with this paragraph, but then I'm not sure 
why we've argued back and forth for a while ;).
 
> >> >No, lock-free synchronization doesn't appear to be an option 
here, 
> >> >unless you've got some technique in mind that I've not seen.
> >> 
> >> Lock-free and no-synchronisation are both options. I'm not sure 
> >what you
> >> are not seeing!
> >
> >As long as (3) above exists you've got problems here.
> 
> I'm still not sure what you are not seeing. Are you confusing the 
idea
> of an option with a rule? One is optional and the other is not. For
> instance, lock-free and no-synchronisation are options for (1), (2) 
and
> (3) depending on their specifics. For the majority of cases in (3),
> however, it ceases to become an option because explicit 
synchronisation
> is definitely required. I am not sure I can put it any more clearly 
than
> that! :-}

I'm not sure that there are any specifics for (3) that would allow 
for lock-free and no-synchronization, other than cases where thread 
boundaries aren't crossed.  In any event, since (3) can't be dealt 
with any where but within the implementation of the function object, 
you've got the problems I've alluded to.  A callback library can not 
address threading issues here as long as cloning is used with out 
cooperation from the wrapped function object, which is intrusive and 
I'm not sure is an option here.

Bill Kempf