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

From: Branko Èibej (branko.cibej_at_[hidden])
Date: 2000-06-06 03:16:14

Beman Dawes wrote:
> Incidently, getting these primitives right includes an error handling
> strategy.  The C++ Standard does not specify the operation of
> exceptions across threads, so presumably exceptions can only be used
> within a thread.

The standard says nothing about threads at all; but it _does_ say that
exceptions are synchronous, so presumably you're right.

>  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.

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.

:-)

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.

Another possibility is to have a hierarchy of thread (base) classes,
which let the programmer chose any behaviour; for example:

        class thread {};			// Implements 1.
        class notify_thread : thread {};	// Implements 3. on top of 1.
        class except_thread : notify_thread {};	// Implements 2. on top of 3.

    Brane

-- 
Branko Èibej                 <branko.cibej_at_[hidden]>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: ([phone]     fax: [phone]