Re: Draft of generation 2 thread class

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
>for
>  > 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
>the
>  > 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.

        disable_cancellations();
        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.

        ~disable_cancellations();
        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 
okay.

Here's some alternate wording that

        disable_cancellations();
        Effects: Temporarily prevents cancellation requests from taking
        effect. Saves the prior disable state.

        ~disable_cancellations();
        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.

Regards,

   Tom

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