From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 09:55:51
--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > I've updated the thread.zip file in the files section with
> > documentation that addresses many of the things brought up
before.
> > I'd appreciate further feedback. I'm especially interested in
> > hearing whether or not the redesign addresses the issues that
> others
> > found prohibitive in the original design. I want to finalize
this
> > stuff soon so that I can actually integrate the changes into the
> > actual library.
> >
> > This brings up a question. For changes such as this do we need a
> > formal review period before integrating into the library? It may
> not
> > seem so for this small change, but when I add the new concepts,
> such
> > as read/write locks, I'm not so sure the answer is the same.
> >
> > Bill Kempf
>
> I would like to suggest adding an extra method to the thread class:
>
> bool is_cancelled() const /* throw() */;
>
> in addition to check_cancelled(). I think having a way to determine
> the cancellation state of a thread with a simple test (as opposed
to
> an exception) could come in handy in some situations:
>
> while( !cur.is_cancelled() ) {
> // do somtheing
> }
> // do some other thing
>
> as opposed to
>
> try {
> while( true ) {
> // do something
> }
> catch( thread_cancel & ) {
> // do some other thing
> }
I'd like to hear some other people's opinion on this one. My first
reaction is that this won't really serve any useful purpose and can
actually lead to poor coding practices, but I've formed bad opinions
in this area before. So, I'd like to hear other people's thoughts.
> Also, I would like to rename `thread_cancel' to `thread_cancelled'
> (BTW, how many Ls are there in this word?). Doesn't that sound
> better? Maybe not, my English is far from perfect.
I have no problems with that change.
Bill Kempf