Re: Implicit thread cancellation
tskorohod@voliacable.com ha scritto:
I've read n2184 and I think that something missing in the proposal. It
allows to point in code places where running thread can be safely
cancelled. But imagine how code that uses cancellation points
extensively will look like:
f1();
this_thread::cancellation_point();
f2();
this_thread::cancellation_point();
f3();
etc.
Something that allows implicit thread cancellation should be added.
For example, we could state that any call to a function which
exception specification allows throwing thread_cancelled exception is
a cancellation_point.
There are several arguments why we should do that:
1) as far as I understand, n2184 is library-only proposal, but the
change you are proposing is a core language issue. Core language issues
require much more rationale to be considered.
2) exception specifications have a different meaning, so their
"overload" in this context looks a little artificial to me. Just my opinion.
3) your proposal requires that the signature of functions f1(), f2()
etc. must be changed. This means that you have access to source code of
the functions and can modify it. If the functions belong to a library
over which you don't have control, your approach is not feasible. But if
you can modify the source, why not doing this instead:
//---- with your proposal
void f1() throw(thread_canceled)
{
// do something here
}
//---- with "plain" n2184
void f1()
{
// do something here
this_thread::cancellation_point();
}
Just my 2 eurocent,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]