From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-04 12:26:27
In which cases is self () actually useful? In all the cases I consider, the
point is to have the function thread-agnostic, unknowing of being threaded
or not. This was one of the problems with changing the throw point, but it
was no longer a problem when the throw point was changed universally.
Are there ways to promote designs where uses of "self ()" are instead pushed
outside of the functor (to some external "manager" type thing)?
----- Original Message -----
From: William E. Kempf
Sent: Wednesday, 2002:September:04 10:35
Subject: Boost.Threads: thread design
I know people have been asking what direction the thread design will take
after the discussion about exception handling and that I've not responded in
quite some time. Sorry, but I'm swamped on my end with a lot of non-Boost
stuff. I have managed to find some time to think about and play with
various design ideas, but I'm not ready to answer the specific questions
people have yet... there's too many little details I need to work out first.
Once I have a design I'm happy with I let everyone know and address all of
In the mean time... I've found some issues with some of the ideas we've
talked about. The biggest among them is with providing a type safe return
value when a thread is joined. The proposal was to make the boost::thread
type templatized on return type, but this causes serious problems with use.
We no longer have a single thread type, but instead have an open ended set
of thread types. Not a big deal from the point of view of the thread
creator, but this renders "self()" operations (the default constructor in
today's design) nearly impossible to use. You have to know what type of
thread "self" is, which isn't possible in many valid use cases. I can think
of a few ways around this, such as having a special thread type usable as a
"self thread" that has no return value and can wrap, or making the return
type a boost::any, but I'm not sure I care too much for any of them. It
still seems cleaner to me to handle the return value semantics through the
function object instead of through the thread object. (And yes, if we
decide to go that route I'll try and provide a lot of the plumbing that will
make such usage as easy as possible for users.)
I'd appreciate thoughts/comments on this issue.
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk