Boost logo

Boost :

From: Hillel Y. Sims (hys420_at_[hidden])
Date: 2001-08-05 00:03:21

Pthreads has a limited, well-defined set of cancellation points (under
ordinary conditions), thus is it 100% possible and not that difficult to
write completely non-throwing code even with thread-cancellation
implemented in terms of exceptions in a pthreads-based environment, by
simply avoiding any functions that could potentially evoke a
thread-cancellation exception (since it's not valid to use catch (...) {}
to swallow these exceptions, we would have to completely avoid invoking
any of these calls inside true non-throwing code, but that doesn't really
seem like a horrible restriction).

(I don't really do Windows, so I don't know if it has similar thread
cancellation semantics..)

That's pretty funny about Java only having asynchronous cancellation, I
didn't know that. I would blow a gasket if I had to deal with asynchronous
cancellation throughout my entire application.



Message: 17
   Date: Fri, 03 Aug 2001 23:27:12 -0000
   From: jbandela_at_[hidden]
Subject: boost.threads [was RE: Re: sockets /network programming

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.


John R. Bandela

Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger

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