Re: [boost] Boost.threads standardization wishlist

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-24 16:28:28

> > No doubt there are choices to be made.  With policy based design,
> > most choices may be implemented within one framework.  This is,
> > after all, the reason for policy based design in the first place.
>
> Surely there must be a limit to the flexibility possible with a policy
> based design, though.

I think if the various desirable features were gathered together then a
common api could be designed that had room for all.   

Where there is a will, there is a way.

> > It makes "my way or the highway" less of an issue.  It lets the user
> > do things the way they want.  It gives them all the choices (perhaps
> > recommending one) .  Choice is what freedom is about.
>
> Well, I don't think anyone has been advocating "my way or the highway"

Sure they have.  Should an exception be thrown? Should it be caught?  Should 
we demand that it be rethrown?   All of these topics had been argued one way 
or another.  All with good reason as well. Nobody _says_ "My way or the 
highway"
but that is the mode of thought.   We must do what Yoda asks and "unlearn", 
that there is a right way and a wrong way.  There are many ways.  Why guess 
which way the user wants, and just offer a generous number to choose from.

Don't take my word on it just revisit the following. Note that none of these 
even discuss implementation details (pthreads or from scratch, signals vs. 
flags etc).

<opinion>
If someone wants to catch(...) everything and loop forever, it's not our
responsibility to prevent this.

--
Peter Dimov
Multi Media Ltd.
</opinion>
<opinion>
(a thread should have a right to die! all 
functions equal!! ;-)
regards,
alexander.
</opinion>
<opinion>
So, all this discussion leads us to:
1) Use deferred cancellation (and allow the user to turn cancellation 
off).
2) Use a C++ exception for cancellation.
3) Allow the user to catch the exception.
4) Allow the user to "eat" the exception.
5) Make the cancellation "flag" a sticky flag, so if the user "eats" 
the exception it will eventually be re-thrown when they call another 
cancellation point.
6) Ensure cancellation points don't throw when uncaught_exception() 
returns true.
7) Document that in general one should always rethrow a caught 
cancelation exception.
Bill Kempf
</opinion>
<opinion>
However, if you don't provide the function above, users may end up with
"unknown exception" error reports caused by thread cancellation, so maybe we
need both. Alexander's trick is a safety net; the other one should always
take precedence.
-Dave
</opinion>
> > God bless America!
>
> And what about everybody else?  Choice is what freedom is about, after
> all.  <smile>
You know, when I go in the grocery store and see an aisle of 101 types of 
cereal this is what I think.   I mean, how many ways are there to prepare 
wheat, rice,  and corn for a breakfast meal.   Lots.   I guess one might say 
there are many ways to "implement" the cereal policy ;-)
God Bless Freedom!
Lee