From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 22:29:51
--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> On Sun, 20 Jan 2002 20:10:40 -0000, "bill_kempf"
> <williamkempf_at_h...> wrote:
> > > In the threading systems I've used, the each thread's main
> > > must catch all exceptions, otherwise bad things can happen.
> > > boost adopts a thread, is that before the thread is running so
> > > there's still a chance to get an exception handler onto the
> > > 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
> >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?
That depends on the platform. Typically it's undefined behavior on
(Boost.Threads, however, will insure the application terminates if an
exception isn't caught by a "boost" thread.)
> 2) In the current implementation, when the thread constructor
> 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?
An adopted thread is one that was created outside of Boost.Threads
and subsequently "adopted", so how it works is platform specific.
> > > It occurred to me that maybe the disable_cancellation class
> > > defer cancellation, rather then prevent it. It isn't clear in
> > > documentation which of the two behaviors it will have. The
> > > deferred cancellation is so the application doesn't have to
> > > trying to cancel a thread until it finally succeeds.
> > > would be simple: disabling/deferring cancellation doesn't
> > > 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
> 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.
No, don't take me wrong. I truly thought I covered the bases in the
documentation, but if things are unclear I have to work on it.
> 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
> what happens at the cancellation point. The first two
> would mean the design is unreliable, the third would be good.
It's actually the second, but what I think is unclear is that I
stated "any" further cancellation points when it's only any further
cancellation points until cancellation is subsequently re-enabled
(which results in your third description.)
> 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",
> that call to cancel I made has a chance to take effect." The first
> interpretation would mean the design is unreliable, the other one
It's the latter. I'll definately try and reword the documentation.
Thanks for the input here.
> Here's some alternate wording that
> Effects: Temporarily prevents cancellation requests from
> effect. Saves the prior disable state.
> Effects: Restores the prior disable state. If there are no
> instances of disable_cancellations for the thread, and there
> 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
Yes. However, I'm heavily leaning towards Dave's idea of counting
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk