Re: [boost] Re: RFC: Multithreading design constraints

From: Beman Dawes (beman_at_[hidden])
Date: 2000-06-06 08:10:33

At 10:16 AM 6/6/00 +0200, Branko =?iso-8859-2?Q?=C8ibej?= wrote:

>>  Would a signal be a useful mechanism to report
>> errors across threads?
>
>My gut reaction is to stay away from signals in threaded code.
>The behaviour of signals differs widely, even between different
>Unix platforms; on Win32, signals are just at thin layer on top
>of SEH (structured exception handling), which works within a
>single thread only.

Sorry, poor choice of words on my part.  I meant signal as in
pthreads "signal a condition variable", not a <signal.h> signal.

>BTW, this is from "Programming with POSIX Threads":
>
>	When writing threaded code, treat signals as Jabberwocks--
>	curious and potentially dangerous creatures to be
>	approached with caution, if at all.
>
>:-)

Agreed.

Note that "Programming with POSIX Threads" also says that by
carefully using the term signal and qualifying it when necessary, "we
are unlikely to cause anyone severe discomfort."

Since I already failed the "careful" test, I suggest that boost not
call it a multithreading "signal" but rather "event" or some other
name.

>Anyway, I see several ways to go:
>
>  1. If an exception is thrown in a thread, and there's no handler
>     registered within the thread, call unexpected().
>
>  2. Put a catch-all handler in the thread start-up function. When
>     an exception is caught there, terminate the thread normally,
but
>     throw an exception when another thread calls join().
>
>  3. Like 2, but just put the thread object in an "exception caught"
>     state, then let the programmer do whatever she wants with that
>     (including throwing an exception).
>
>Personally I'd go for 1., because it's closest to current standard
>behaviour. Besides, it's the most flexible -- both 2. and 3. can
>be implemented on top of it.

Let me make sure I understand (1). Are you saying that the apparent
thread startup function is actually called from a private library
startup function which wraps the call to the apparent startup
function in a try...catch?  Hum. That does seem like a good idea!

--Beman