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.
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
>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,
> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk