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                      ]

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.

> 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. 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.


---
[ 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                      ]

tskorohod@voliacable.com ha scritto:
>> 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.

As far as I know, cancellation point may potentially require some
overhead. If you implicitly make any function without exception
specification a cancellation point, then you are violating the C++
golden rule "you don't pay for what you don't need" as a multithreaded
program will have to pay such overhead for *every* function call even if
it never uses cancellation. Moreover, it would make it nearly impossible
to efficiently inline function calls unless the programmer puts empty
exception specifications all over the place.

Just my opinion,

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                      ]

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                      ]

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.

---
[ 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                      ]