From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-23 10:57:39
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > Ending a thread:
> > No library support is necessary.
> Uhmm... you describe the necessary library support below ;).
I meant that no special thread::exit() function is necessary.
> Just curious, what would a derived type be good for? I'd expect that
> thread::cancel (and maybe thread::exit) would be the only methods
> that could throw this exception so we wouldn't have derived types any
Well, a catch() handler for thread_end will always catch derived types as
well; right now I don't see any use for a derived type except not
over-constraining implementations. When canceling a thread, the
implementation should probably be allowed to throw different exceptions in
different situations, as long as they are derived from thread_end.
> You *MUST* include the ability to change cancelability for a thread.
Yes, you're probably right. This is a 'phase 0' proposal.
> > Suspending/resuming a thread:
> I'm not sure we should include these.
I'm not sure either. The methods are safer when a suspended thread is
treated as a resource, and the suspend/resume calls are wrapped in a RAII
object, similar to scoped_lock. That's why thread::resume is not a
cancelation point. :-)
Still, deadlocks are possible.
> > thread::suspend is a cancelation point.
> Why? It's not a blocking operation for the thread calling it, so
> making this a cancelation point doesn't make much sense.
thread::suspend() accesses a shared object - the thread state - and can,
therefore, be a blocking operation since the access will need to be
serialized. At least that's how I look at it; I may be wrong.
> > Opinions? This behavior (with one minor exception) is implementable
> now, at
> > least on paper.
> What's the minor exception?
Well you have identified it yourself, it's catching thread_end escaping from
main(). For now we'll probably have to provide thread_main() instead. :-)
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk