Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-11 10:39:15

--- In boost_at_[hidden], "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: "William Kempf" <sirwillard_at_m...>
> 
> > Check out the implementation for the Win32 Boost Thread Library in
> > the file archives.  This specifically was what raised the current
> > round of discussion on this topic.  Sigc++ style "callbacks" are 
not
> > appropriate here for several reasons:
> 
> I already understood the reasons; what I'm still missing is 
why "callbacks"
> would be needed for a threading library.

Well, I think the code speaks for itself there, but I'll elaborate 
any way.

Threads must be created by passing a callback into the creation 
process that represents the work the thread will perform.  C thread 
libraries use a simple function pointer for this task, but this isn't 
appropriate in C++ because it's not type safe and ignores the 
presence of objects.  Java goes to the other extreme, where the 
callback is an object derived from Runnable where the Run() method 
represents the unit of thread work.  This is better, IMHO, then a 
function pointer because it's OO, but it ignores stand alone 
functions and so isn't the proper solution for C++ either.  Function 
objects, however, easily cater to both functions and objects as 
callbacks.  Their only problem is that they are not polymorphic, 
making it difficult (if not impossible in a portable manner) to 
implement over the C style thread libraries available to us.  It's an 
implementation detail, but a very important one.

There are numerous other concepts that would require such callbacks 
as well.  How about thread clean up stacks, for instance?  Or the 
ScopeGuard referred to early on this list (though it uses a more 
optimized implementation)?  Specialized Subject/Observer cases?  
State machine implementations where you register work to be done when 
a state is entered?

Bill Kempf