From: williamkempf_at_[hidden]
Date: 2001-08-23 10:27:16
--- 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 ;).
> A thread can terminate itself by throwing
> an exception of type "thread_end" or a type derived from thread_end.
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
way.
> When a thread_end (or derived) exception escapes from the thread
procedure
> (function object operator()), the thread is terminated as if it had
returned
> normally.
>
> When an exception other than thread_end (or derived) escapes from
the thread
> procedure, {boost,std}::thread_terminate() is called. It does
nothing by
> default unless a user-specific handler has been installed via
> set_thread_terminate(handler), in which case that handler is
invoked. The
> thread is then terminated as if it had returned normally.
This has been proposed on this list already. Problems with the idea
have been pointed out, but it's likely the best (only?) answer so it
will likely be used by Boost.Threads when cancellation is added. The
inclusion of set_thread_terminate() is a nice addition.
> When a thread_end (or derived) exception escapes from main(), the
main
> thread (but not the process) is terminated.
Impossible to gaurantee with out either language support or an
annoying "BoostThreadInit" type of solution.
> When an exception other than thread_end (or derived) escapes from
main(),
> the behavior is as already specified in the standard.
>
> Canceling a thread:
>
> When thread::cancel() (nonstatic) is called the thread goes into
canceled
> state.
You *MUST* include the ability to change cancelability for a thread.
This is especially true if exceptions are used, lest you terminate
the program abnormally when a destructor calls a cancellation point
during stack unwinding from another exception.
> When a canceled thread calls a function that is a cancelation point
[and
> std::uncaught_exception() returns false?], this function throws an
exception
> of type thread_end (or derived.)
Hmm.. the check for std::uncaught_exception can achieve nearly the
same thing as changing the cancelation state, but I think we still
need this ability.
> Cancelation points are mutex::lock (by default), condition::wait,
> thread::sleep, thread::yield, thread::join,
thread::cancelation_point
> (static), thread::cancel.
At a minimum. POSIX defines several other cancelation points.
> Suspending/resuming a thread:
>
> When thread::suspend() (nonstatic) is called, that thread's
execution is
> suspended by the system no later than the first encountered
cancelation
> point.
I'm not sure we should include these. They are extremely error prone
and almost always lead to deadlocks. The one time they are useful
and safe is when the thread is created suspended and resumed after
some initialization (such as the solution I gave you earlier). But
since this one case can be achieved via a "monitor" I'm not so sure
that this is reason enough to include these dangerous routines.
> 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::resume() (nonstatic) resumes a suspended thread.
>
> Opinions? This behavior (with one minor exception) is implementable
now, at
> least on paper.
What's the minor exception?
Bill Kempf