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

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 08:01:59

>Since both are viable, both solve the problems, and both have proponents 
>and
>opponents, we're left in a sticky situation.  Concensus is not going to be
>achieved by arguing the technical merits of the case.  In the end, it's 
>going
>to come down to opinion.  Here's mine:
>
>Have the default beviour be for threads to terminate on uncaught 
>exceptions.
>
>I base this simply on my opinion that a thread() is different from an
>async-call and that the thread library has tried to remain a low-level
>library that provides us the tools for writing higher-level abstractions
>(which is why it doesn't provide monitor classes etc).

Thank you.  Though I don't expect this post to convince everyone, you've 
stated what I've been trying to much better than I have thus been able to.  
You've captured the issues well enough to make the stance I've taken 
understandable to others (I hope), even if they have a different opinion.  
You've provided me with well written rationale here!

>This leaves us with an opportunity for someone to introduce an async-call
>framework.  Perhaps a simple-library for now (that solves the problems that
>people want from the thread library), but perhaps being sufficiently
>extensible that you can plug in support for remoting etc.

This would, indeed, be a useful higher level construct.  I'd point out that 
creating a thread on demand here would likely be a poor choice.  This is 
what thread pools were designed for.  And I'd like to see other forms of 
async calls supported, such as RPCs and even constructs such as the Win32 
message queue.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com