Re: Which libraries in Boost are mature enough to be used in real applications?
David Abrahams wrote:
"kanze" <kanze@gabi-soft.fr> writes:
David Abrahams wrote:
[...]
If that's what you think Boost.Threads (or most any Boost
library) is, you really have no concept of how that library
was developed. It is by no means perfect, but even more
than most Boost libraries, Boost.Threads was entirely based
on extensive research of well-established existing practice.
In the case of the thread library, this isn't necessarily a
good thing. My impression of "existing practice" of
multi-threaded programs is that they tend to hang or crash at
odd moments:-)
Yes, but that's because multithreaded programming is hard, and
the abstractions that make it easy and/or foolproof are at
best a few years off *today* (to say nothing of when
Boost.Threads was designed). The strongest abstractions and
clearest reasoning then, as now, for threaded programming come
from pthreads, AFAICT.
For what I'm doing, the pthread abstraction, with some added
restrictions (e.g. a requirement to stop all threads before
calling exit), is adequate. But different users have different
requirements, and for some (including some of the oldest and
best understood), pthreads is inadequate.
But that wasn't my point -- most of the problems I run into
don't stem from pthreads themselves, but from the way people use
them. I have a couple of objections concerning boost::threads,
but that wasn't the point of my posting.
(and that those which don't act like this today will as soon
as they start running on a multi-processor or a multi-core
system).
(This isn't to say that having a nice, portable wrapper for
the underlying system calls isn't a good thing. Just that
there are limits to what you can do to ensure safe
programming, when what is or is not safe isn't really
understood by your users.)
(so basically what you're saying has nothing to do with the
argument at hand about whether the design was "baked"...)
(...right?)
Other than, perhaps, to suggest that a perfect abstraction isn't
always possible. Realistically, I don't think we can wait ten
or fifteen years until we know what the "correct" solution is to
start thinking about providing a portable wrapper. At some
point, even half-baked is better than raw dough. (Note that my
criticisms concerning boost::threads generally concern points
where I find that it hides the underlying pthreads abstraction
too much. Things like not being able to use non-scoped locks
when appropriate, or having threads "accidentally" become
detached because of an exception, so that I can't shut them down
cleanly.)
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]