[boost] Re: Attempting resolution of Threads & Exceptions Issue

From: Alexander Terekhov (TEREKHOV_at_[hidden])
Date: 2002-08-13 09:46:21

Peter Dimov wrote:
[...]
> This is a valid concern, but it's possible to have the cake and eat it,
too.
> Provide the "unsafe" interface, where thread<R> propagates, as an
> experiment. Wait for user feedback. Obtain real data on whether the
mistakes
> caused by this behavior are a significant problem, and not a small part
of
> the vast majority of thread-related errors. Nobody argues with real data.
> :-)

If you really want/need it, why don't you simply "wrap" a function
throwing something useful [that you'd EXPECT and are really going to
HANDLE in the joined thread(s)] using some return-value/exception(s)-
variant-holder-functor that would propagate EXPECTED exceptions caught
and in it's launching/landing-"pad" function-wrapper ON RETURN VALUE
EXTRACTOR "method" invocation [or f.ex.pthread->join()->
throwCaughtExceptionIfAny() for void operations, thread cancellation
aside in this case]?

Consider that thread join/timedjoin/tryjoin interface would have to
return A POINTER to a wrapper object [stored-in/managed-by thread
object] anyway -- to indicate NO-RESULT and STILL-RUNNING conditions
[unique pointers] as the consequence of thread cancelation and timed-
out/still-busy timedjoin() and tryjoin() calls.

Well, as for "Nobody argues with real data"... consider the following
opinions [Mr. Butenhof, of course]:

"POSIX threads do not have parent-child relationships. All threads
 are peers, and as nearly equal as possible. (The only real exception
 is that a return from most threads is equivalent to pthread_exit()
 while a return from the initial thread [main()] is equivalent to
 exit(), terminating the process.)

 DCE did try to build this sort of hierarchy for RPC relationships;
 an exception that terminated an RPC server routine would propagate
 to the stub routine in the client (caller). This proved REALLY
 annoying; but of course in that case exception support was primitive
 (C macros) and we were propagating the exception (sans stack context)
 across address spaces and even architectures/operating systems."

"There are exceptions, and building cancellation on, well, exceptions,
 allows a clean implementation in such cases. The original application
 was DCE. DCE was designed to propagate a cancel across the RPC link
 from server to client, unwinding the "virtual call stack". (Not
 necessarily a good idea since they're in different address spaces,
 but that's beside the point.) However, although the server routine
 might be cancelled, the server thread would remain to run other
 instances. Therefore, the "wrapper" would catch (and finalize) any
 exception (including cancel) raised by the RPC server routine, and
 propagate it through the comm link to the client, while continuing
 to run normally. There are very few examples where a scheme like
 this makes any sense."

regards,
alexander.