Boost logo

Boost :

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
> > 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

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