On Tue, Aug 15, 2017 at 05:37:21PM +0100, Szabolcs Nagy wrote:
> On 15/08/17 16:47, Richard Biener wrote:
> > On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote:
> >> Is changing the cancellation state really an expensive operation?
> >> Moreso than the checking which I assume already needs to be done for
On Tue, Aug 15, 2017 at 05:39:10PM +0100, Jonathan Wakely wrote:
> On 15 August 2017 at 16:21, Ron wrote:
> > On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
> >> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
> >> wrote:
> >> > On 15 August 2017 at 11:24, Richard Biener
> >>
On 15 August 2017 at 17:39, Jonathan Wakely wrote:
> Also currently std::thread runs the supplied function object inside a
> noexcept function. With your proposal cancellation would be blocked in
> any thread created by a std::thread, i.e. you could only cancel in the
> main() thread, or threads cr
On 15 August 2017 at 16:21, Ron wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
>> wrote:
>> > On 15 August 2017 at 11:24, Richard Biener
>> > wrote:
>> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
>> >>> On Mon, A
On 15/08/17 16:47, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote:
>> Is changing the cancellation state really an expensive operation?
>> Moreso than the checking which I assume already needs to be done for
>> noexcept to trap errant exceptions?
>
> The noexcept checking only
On 15/08/17 16:21, Ron wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
>> wrote:
>>> On 15 August 2017 at 11:24, Richard Biener
>>> wrote:
On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
> On Mon, Aug 14, 2017 at
On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
>> wrote:
>> > On 15 August 2017 at 11:24, Richard Biener
>> > wrote:
>> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
>> >>> On M
On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
> wrote:
> > On 15 August 2017 at 11:24, Richard Biener
> > wrote:
> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely
On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely wrote:
> On 15 August 2017 at 11:24, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
>>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
On 13 August 2017 at 19:20, Ron wrote:
>
> Hi,
>
>>>
On 15 August 2017 at 11:24, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>>> On 13 August 2017 at 19:20, Ron wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm looking for some clarification of how the __forced_unwind
On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>> On 13 August 2017 at 19:20, Ron wrote:
>> >
>> > Hi,
>> >
>> > I'm looking for some clarification of how the __forced_unwind thread
>> > cancellation exceptions intersect with noexcept
On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
> On 13 August 2017 at 19:20, Ron wrote:
> >
> > Hi,
> >
> > I'm looking for some clarification of how the __forced_unwind thread
> > cancellation exceptions intersect with noexcept. I've long been a
> > big fan of the __forced_unwin
On 13 August 2017 at 19:20, Ron wrote:
>
> Hi,
>
> I'm looking for some clarification of how the __forced_unwind thread
> cancellation exceptions intersect with noexcept. I've long been a
> big fan of the __forced_unwind idiom, but now that C++14 is the default
> since GCC 6.1, and many methods in
Hi,
I'm looking for some clarification of how the __forced_unwind thread
cancellation exceptions intersect with noexcept. I've long been a
big fan of the __forced_unwind idiom, but now that C++14 is the default
since GCC 6.1, and many methods including destructors are implicitly
noexcept, using
14 matches
Mail list logo