Boost logo

Boost :

From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-20 18:09:34

On Sun, 20 Jan 2002 20:10:40 -0000, "bill_kempf"
<williamkempf_at_[hidden]> wrote:
> > In the threading systems I've used, the each thread's main function
> > must catch all exceptions, otherwise bad things can happen. When
> > boost adopts a thread, is that before the thread is running so
> > there's still a chance to get an exception handler onto the top of
> > its stack? If not, how will an adopted thread keep exceptions
> > contained to the thread?
>There's no way to adopt a thread before it exists. No, thread
>adoption won't have any impact on exception safety. This is one area
>where we need language support and the library can't help us.

I'm still confused and a little bit concerned. Let me try asking
again and hopefully more clearly:

1) Is it correct that the thread function needs to have a top level
try/catch block in order for the thread to be exception safe?

2) In the current implementation, when the thread constructor starts
a new thread of execution, it actually starts the thread with a
thread_proxy function that has a try/catch block and calls the
threadfunc. This seems good to me. How is the equivalent process
going to work for an adopted thread?

> > It occurred to me that maybe the disable_cancellation class should
> > defer cancellation, rather then prevent it. It isn't clear in the
> > documentation which of the two behaviors it will have. The reason
> > deferred cancellation is so the application doesn't have to keep
> > trying to cancel a thread until it finally succeeds. Implementation
> > would be simple: disabling/deferring cancellation doesn't prevent
> > cancel flag from being set, just from being acted on.
>I thought the documentation covered this well enough. Nothing ever
>prevents another thread from requesting the thread be cancelled.
>Disabling simply means that cancellation points do not throw
>regardless of any such pending requests.

I think your design is correct or very close to it. It's just that I
have been burned by poorly designed thread packages before, so I'm
always going to take a slightly paranoid approach to reading the
documentation, and I expect I'm not the only developer who may feel
that way.

        Effects: Disables all requests for cancellation. Any further
        calls to any "cancellation points" will be ignored.

It's not clear to me what a "request" is. It could be the cancel()
function, or it could be the flag that cancel() sets, or it could be
what happens at the cancellation point. The first two interpretations
would mean the design is unreliable, the third would be good.

        Effects: Returns the cancellability of the thread to the state
        it was in prior to the construction of *this.

It isn't clear whether "restoring the cancellability of the thread"
applies to the cancellation flag or to the cancellation points, and
it could be read as "now I can call cancel and it will work", or "now
that call to cancel I made has a chance to take effect." The first
interpretation would mean the design is unreliable, the other one is

Here's some alternate wording that

        Effects: Temporarily prevents cancellation requests from taking
        effect. Saves the prior disable state.

        Effects: Restores the prior disable state. If there are no more
        instances of disable_cancellations for the thread, and there is
        a pending cancellation request, the cancellation request will
        take effect when the thread calls a cancellation point.

This isn't perfect, but I hope it gives you an idea of what I'm thinking.



Tom Becker                      "Within C++, there is a much smaller and
<voidampersand_at_[hidden]>        cleaner language struggling to get out."
                                                       -- Bjarne Stroustrup

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