Re: boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-03 19:13:01

----- Original Message -----
From: <jbandela_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 03, 2001 7:27 PM
Subject: boost.threads [was RE: [boost] Re: sockets /network programming
Requirements]

> In GOTW 61 Herb Sutter writes the following
>
> The Importance of "Big-A" Atomicity
> As pointed out by Abrahams and Colvin and others, to guarantee any
> kind of exception safety it is essential that certain operations --
> notable destructors and deallocation functions -- be required not to
> throw. That is, they must be at least A-safe. We rely on this in all
> sorts of situations, notably:
>
> - The "do all the work off to the side, and commit using only
> nonthrowing operations" method is not possible if there are no
> suitable nonthrowing (A-safe) operations.
>
> - The related "create a temporary and Swap()" method, which is the
> standard form of exception-safe copy assignment, is not possible
> without a nonthrowing (A-safe) Swap().
>
> An interesting point raised by Greg Colvin is that for this reason it
> does not appear to be possible to write exception-safe code in Java.
> The Java specification currently allows the JVM to throw an exception
> at any time at arbitrary points in the program, for example
> asynchronously when stop is called on a Thread object. In practice it
> isn't that bad, but it is worrisome that the Java specification can
> apparently be shown to preclude writing exception-safe code because
> there is no way to absolutely guarantee A-safe operations in Java.
>
> -----
>
> Are the statements about arbitrary exceptions precluding the writing
> of exception safe code still valid? It seems to me that using
> exceptions to interrupt threads would, according to the above
> passage, preclude writing guaranteed exception-safe code.

I still don't know what Herb meant by "A-safe". Maybe it's just
"nonthrowing".

Anyway, as I said, I haven't been following closely. There's no reason an
exception couldn't be used within a thread to interrupt it, so long as the
exception never appeared in some other thread (e.g. the one that spawned the
interrupted thread). One way I can imagine that happening is that the thread
package has a top-level function that looks like

try {
  call_thread_main();
}catch(interrupted_thread const&) {
  // do something
}
catch(...) {
  // do something else
}

What's definitely unacceptable is any arrangement that could turn an
operation written to be nothrow (e.g. integer assignment) into a throwing
operation.

-Dave