Re: Implicit thread cancellation
On Mar 25, 12:05 am, tskoro...@voliacable.com wrote:
On 24 ???, 17:17, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
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.
It seems to me that thread cancellation should be a core language
feature.
Why?
I happen to agree with you (sort of, anyway), but the current
proposal uses existing mechanisms (i.e. exceptions) to propagate
the cancellation. What sort of core language support did you
have in mind?
2) exception specifications have a different meaning, so their
"overload" in this context looks a little artificial to me. Just my opinion.
I could explain how I came to that suggestion. I looked at mechanism
of aborting threads in .NET. In .NET every instruction may throw an
exception.
Which means that exception safe code is pretty much impossible,
no?
So when a thread abort is requested .NET just throws an
exception in the context of that thread. (I may be wrong in some
details but that doesn't matter).
I thought that it would be good to have similar mechanism in C++. But
in C++ not every instruction is allowed to throw an exception. At
least, we should exclude functions that have empty exception
specification. And my first (not posted) suggestion was to allow
aborting threads at the beginning of functions that may throw some
exception.
But that may break code that relies on exception specifications...
3) your proposal requires that the signature of functions f1(), f2()
etc. must be changed.
Not always. Exception specifications are rarely used. So if f1 has no
exception specification then it may throw any exception and can be
considered as cancellation point.
But why should it be? Cancellation is only safe at points where
the programmer intends it to be. Your proposal would force
extensive use of exception specifications, since most of the
time, cancellation is *not* safe.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ 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 ]