Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-10-21 Thread Gleb Natapov
On Fri, Oct 21, 2016 at 02:58:26PM +0300, Gleb Natapov wrote: > On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote: > > On 21/10/16 14:36 +0300, Gleb Natapov wrote: > > > On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote: > > > > Are excepti

Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-10-21 Thread Gleb Natapov
On Fri, Oct 21, 2016 at 12:44:39PM +0100, Jonathan Wakely wrote: > On 21/10/16 14:36 +0300, Gleb Natapov wrote: > > On Thu, Oct 20, 2016 at 11:53:49PM -0400, Ryan Burn wrote: > > > Are exception classes required to support emplace new construction > > > like that? Wi

Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-10-21 Thread Gleb Natapov
B exception objects only by means of applying > move() > operation on an exception thrown out of TBB scheduler. **/ > void* operator new ( size_t ); > > > > On Mon, Aug 22, 2016 at 1:29 PM, Jonathan Wakely <jwak...@redhat.com> wr

Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-08-21 Thread Gleb Natapov
Jonathan, Is this version OK with you? On Fri, Aug 05, 2016 at 07:49:24AM +0300, Gleb Natapov wrote: > Instead of throwing an exception allocate its memory and initialize it > explicitly. Makes std::make_exception_ptr more efficient since no stack > unwinding is needed. > > v

Re: [PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-08-21 Thread Gleb Natapov
On Fri, Jul 29, 2016 at 11:22:18AM -0600, Jeff Law wrote: > On 07/29/2016 11:19 AM, Gleb Natapov wrote: > > > > I'll table your patch on that assumption. > > OK. Can you ping him about it after he will back or should I (although in > > another week I will be on PTO

Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-08-05 Thread Gleb Natapov
On Fri, Aug 05, 2016 at 07:56:02AM +0200, Daniel Krügler wrote: > 2016-08-05 6:49 GMT+02:00 Gleb Natapov <g...@scylladb.com>: > > Instead of throwing an exception allocate its memory and initialize it > > explicitly. Makes std::make_exception_ptr more efficient since n

[PATCHv2] do not throw in std::make_exception_ptr

2016-08-04 Thread Gleb Natapov
Instead of throwing an exception allocate its memory and initialize it explicitly. Makes std::make_exception_ptr more efficient since no stack unwinding is needed. v1->v2: - fix indentation - drop static from __dest_thunk - use static_cast instead of reinterpret_cast * libsupc++/exception

Re: [PATCH] do not throw in std::make_exception_ptr

2016-08-04 Thread Gleb Natapov
On Thu, Aug 04, 2016 at 07:01:45PM +0100, Jonathan Wakely wrote: > On 04/08/16 20:01 +0300, Gleb Natapov wrote: > > Instead of throwing an exception allocate its memory and initialize it > > explicitly. Makes std::make_exception_ptr more efficient since no stack > >

[PATCH] do not throw in std::make_exception_ptr

2016-08-04 Thread Gleb Natapov
Instead of throwing an exception allocate its memory and initialize it explicitly. Makes std::make_exception_ptr more efficient since no stack unwinding is needed. In this version I hopefully addressed all Jonathan comments. * libsupc++/exception (std::exception): Move... *

Re: [PATCH RFC] do not throw in std::make_exception_ptr

2016-08-03 Thread Gleb Natapov
On Wed, Aug 03, 2016 at 12:47:30PM +0100, Jonathan Wakely wrote: > > > > > > > + } // namespace __exception_ptr > > > > > > > > /// Obtain an exception_ptr pointing to a copy of the supplied object. > > > > template > > > > @@ -173,7 +184,15 @@ namespace std > > > > #if __cpp_exceptions > >

Re: [PATCH RFC] do not throw in std::make_exception_ptr

2016-08-03 Thread Gleb Natapov
On Wed, Aug 03, 2016 at 10:48:27AM +0100, Jonathan Wakely wrote: > On 28/07/16 10:20 +0300, Gleb Natapov wrote: > > [resent with hopefully correct libstdc++ mailing list address this time] > > > > Here is my attempt to fix > > https://gcc.gnu.org/bugzilla/show_bug.

Re: [PATCH RFC] do not throw in std::make_exception_ptr

2016-07-31 Thread Gleb Natapov
On Sun, Jul 31, 2016 at 02:28:51PM +0100, Jonathan Wakely wrote: > On 28/07/16 10:20 +0300, Gleb Natapov wrote: > > [resent with hopefully correct libstdc++ mailing list address this time] > > > > Here is my attempt to fix > > https://gcc.gnu.org/bugzilla/show_bug.

Re: [PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-29 Thread Gleb Natapov
On Fri, Jul 29, 2016 at 10:54:21AM -0600, Jeff Law wrote: > On 07/29/2016 10:03 AM, Jeff Law wrote: > > > > It's been a couple years since I've really thought about these kinds of > > > > synchronization issues -- is it really safe in a weakly ordered > > > > processor to > > > > rely on the mutex

Re: [PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-29 Thread Gleb Natapov
On Fri, Jul 29, 2016 at 10:03:53AM -0600, Jeff Law wrote: > On 07/27/2016 10:24 PM, Gleb Natapov wrote: > > On Wed, Jul 27, 2016 at 05:12:18PM -0600, Jeff Law wrote: > > > On 07/25/2016 07:44 AM, Gleb Natapov wrote: > > > > _Unwind_Find_FDE calls _Unwind_Find_re

[PATCH RFC] do not throw in std::make_exception_ptr

2016-07-28 Thread Gleb Natapov
[resent with hopefully correct libstdc++ mailing list address this time] Here is my attempt to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68297. The resulting patch is a little bit long because I had to split and cxxabi.h include files. The former had to be split due to circular dependency

[PATCH RFC] do not throw in std::make_exception_ptr

2016-07-28 Thread Gleb Natapov
Here is my attempt to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68297. The resulting patch is a little bit long because I had to split and cxxabi.h include files. The former had to be split due to circular dependency that formed after including in exception_ptr.h and the later is because

Re: [PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-27 Thread Gleb Natapov
On Wed, Jul 27, 2016 at 05:12:18PM -0600, Jeff Law wrote: > On 07/25/2016 07:44 AM, Gleb Natapov wrote: > > _Unwind_Find_FDE calls _Unwind_Find_registered_FDE and it takes lock even > > when there is no registered objects. As far as I see only statically > > lin

[PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-25 Thread Gleb Natapov
_Unwind_Find_FDE calls _Unwind_Find_registered_FDE and it takes lock even when there is no registered objects. As far as I see only statically linked applications call __register_frame_info* functions, so for dynamically linked executables taking the lock to check unseen_objects and seen_objects

Re: [PATCH RFC] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-24 Thread Gleb Natapov
Thank you for prompt review. On Sun, Jul 24, 2016 at 11:00:53AM -0700, Andrew Pinski wrote: > On Sun, Jul 24, 2016 at 8:01 AM, Gleb Natapov <g...@scylladb.com> wrote: > > _Unwind_Find_FDE calls _Unwind_Find_registered_FDE and it takes lock even > > when there is no registered

[PATCH RFC] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

2016-07-24 Thread Gleb Natapov
_Unwind_Find_FDE calls _Unwind_Find_registered_FDE and it takes lock even when there is no registered objects. As far as I see only statically linked applications call __register_frame_info* functions, so for dynamically linked executables taking the lock to check unseen_objects and seen_objects