220 34135 <25f81ffc-011d-4ba3-9eac-5e130638a03a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: crusader.mike@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [proposal] specify behavior in case of exception allocation failure Date: Thu, 24 Aug 2017 19:02:26 -0700 (PDT) Lines: 164 Approved: news@gmane.org Message-ID: <25f81ffc-011d-4ba3-9eac-5e130638a03a@isocpp.org> References: <32371a6e-9717-4e31-b939-4cb2d6f09c88@isocpp.org> <35f512f9-a69f-42ae-b7b7-090a3d6dfe96@isocpp.org> <2180216.6Peda3kyM6@tjmaciei-mobl1> <19c778a1-649e-48fd-ba1f-6d6c067d6d37@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2105_1915166498.1503626546212" X-Trace: blaine.gmane.org 1503626548 2405 195.159.176.226 (25 Aug 2017 02:02:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2017 02:02:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMRQUSRIMBBM4K73GAKGQERI4MVUQ@isocpp.org Fri Aug 25 04:02:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dl3wz-0000Dj-DB for gclcip-std-proposals@m.gmane.org; Fri, 25 Aug 2017 04:02:21 +0200 Original-Received: by mail-qk0-f199.google.com with SMTP id l65sf4497052qkc.12 for ; Thu, 24 Aug 2017 19:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=9tuWGx6JebeCT7N8AnRm7z/3D1Ds7/Fqi177i9xDzKU=; b=I91UOCJrDVDvjmI1nuI7vxzzyvQuRypzEtMfovvON6Dni6qcW700OLwMRgGJBFTEp9 SnPbKsPysKwOoMTEgpyuZixjfE8aOxYzovHPS+LhOv3s8AELULOyFBSkCZW3TAoHpL5c gNJ7O6MVY3k9rNoK2oMyl9AIuX3cFqKWT78P/Ce0UnlI7wHn7TdxZqJcQbEFtuKyfHmD W0m8wps+AxFks+BJBeA0qGvrR7W8lwK7NHdVLjHHwd9XH/A6YeIJh7VRFIS5HSc0OIsI q90WmOlfR/cmMmafUMuaCOc8tuJwHHc3z8R0ZKZJc1qe9T2D9aAzPTc/vCAZ0Jbt5657 /2QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=9tuWGx6JebeCT7N8AnRm7z/3D1Ds7/Fqi177i9xDzKU=; b=JpJz310M1eKCqJwFLFLKfXrG7sPVuGcX6GhQx2BfGE1+Zn2iNiOLSgMOqw7frww6Nh aRPueaHSjnfVlHuJZZ0OlgJDlWQZVJ0d/80ZIOQ4fisWoYxzDWMFyMGqdwRcFI4UWzGe wwdhD49H59V2uDKzVbkhUXa7YsW+bczNHd5qUIAHDRFnjrIJEVOzoVq54kcEAmiw6/ba MR/O27tBb08APhgXJtVt50p4f3hKNnbX+L+ZbT4em7zuXiUHcdzgSEVmgm76vW1H6Xob ye8gHPy/ZUpMEYOtu7NNyqDJrr4Y5Q31M6JbeJzQJE9g8rv0VvrwBbByW+O3fVboAAIS ydhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=9tuWGx6JebeCT7N8AnRm7z/3D1Ds7/Fqi177i9xDzKU=; b=dYPQIVvDabwD09EbKDALTiZHyCUd7VfiG1oFFhiDISWi9Qv4H+x6T9z/gPriFqHim/ LmeXeynzLCQAAya+avZ8JA0QNuEG+3l5IzIk8HfroQnAwRpnEzU6iY7kJIqd60PVc3eP YP1ZDbSDUpwZtv13Ys7wRZaP4OjF9yJT2WJsMC7vQhKb0U0Z9zJ/MqziKlnMgt18jzsp y0g7R2jaWV13yYM54Leg4iZTPxKNLdXzWMNJ8h4/8bNf2G2EhWHKmlzoVNZDkhpU8skk 6Mdjgizu+UyeEyUnUipgDm3B+D+uz1ZWQ7qYIy3n6OtVxZ4X9cGzE9tWIwWkRBUZGPEs el1w== X-Gm-Message-State: AHYfb5g3lmv5JSDWX+Kr/oAbw9B6egAfCMVKP0Tk/DInafGzAvWtrxBI h4x4G4zd4ntJLIJZ X-Received: by 10.237.60.138 with SMTP id d10mr5900187qtf.11.1503626548146; Thu, 24 Aug 2017 19:02:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.134.70 with SMTP id i67ls4883941iod.12.gmail; Thu, 24 Aug 2017 19:02:26 -0700 (PDT) X-Received: by 10.31.63.197 with SMTP id m188mr78987vka.9.1503626546752; Thu, 24 Aug 2017 19:02:26 -0700 (PDT) In-Reply-To: <19c778a1-649e-48fd-ba1f-6d6c067d6d37@isocpp.org> X-Original-Sender: crusader.mike@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:34135 Archived-At: ------=_Part_2105_1915166498.1503626546212 Content-Type: multipart/alternative; boundary="----=_Part_2106_792816165.1503626546212" ------=_Part_2106_792816165.1503626546212 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, August 24, 2017 at 5:12:11 PM UTC-5, Ray Hamel wrote: > > On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O'Dwyer wrote: >> >> I don't think either of you have considered that there may be multiple= =20 >> exceptions in-flight (or else I'm missing something fundamental that you= 're=20 >> both assuming implicitly). >> >> Suppose we preallocate 16 bytes so that we can throw runtime_error... an= d=20 >> then we do throw it... and then, while unwinding the stack, we throw=20 >> *another* instance of runtime_error. Don't we now have to get *another*= =20 >> 16 bytes of storage from somewhere? >> Not to mention, even if we only throw zero-byte objects, there's still a= =20 >> certain amount of overhead just for the bookkeeping... I *think*. Please= =20 >> let me know if I'm missing something here. >> >> See my earlier reply in this thread, which included a program that has= =20 >> about 100 exceptions in-flight at once. >> >> =E2=80=93Arthur >> > > Different idea; what about a function `set_oom_buffer` with the prototype > > // allocates an implementation-defined global thread-safe buffer > template > void std::set_oom_buffer(); > > and/or > > // registers a buffer (UB to access or deallocate after registering) > void std::set_oom_buffer(void *buffer, std::size_t n) noexcept; > > The buffer may be used by the constructor of `std::exception` and=20 > subclasses, and to construct other implementation (or user?)-defined=20 > objects, in the event that normal allocation fails. > > This has the advantage of (mostly) maintaining the "you don't pay for wha= t=20 > you don't use" principle, is relatively easy to implement and wouldn't=20 > alter the semantics of existing programs. > > -Ray > Problem is that in this case I need to correctly pre-calculate my=20 'exception memory' requirements for my program to be reliable. What is=20 proposed is to have a universal solution... which can be a "safety net" for= =20 your proposal in case if buffer is too small or program is written in such= =20 way that these requirements aren't bounded. =20 --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/25f81ffc-011d-4ba3-9eac-5e130638a03a%40isocpp.or= g. ------=_Part_2106_792816165.1503626546212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, August 24, 2017 at 5:12:11 PM UTC-5, = Ray Hamel wrote:
On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O'Dwyer wro= te:
I don't thi= nk either of you have considered that there may be multiple exceptions in-f= light (or else I'm missing something fundamental that you're both a= ssuming implicitly).

Sup= pose we preallocate 16 bytes so that we can throw runtime_error... and then= we do throw it... and then, while unwinding the stack, we throw another= instance of runtime_error. Don't we now have to get another= 16 bytes of storage from somewhere?
Not to mention, even if we o= nly throw zero-byte objects, there's still a certain amount of overhead= just for the bookkeeping... I think. Please let me know if I'm = missing something here.

See my earlier reply in th= is thread, which included a program that has about 100 exceptions in-flight= at once.

=E2=80=93Arthur
<= /blockquote>

Different idea; what about a function `set_oom_buffer` with t= he prototype

// allocates an implementation-def= ined global thread-safe buffer
= template<std::size_t N>= ;
vo= id std:= :set_oom_buffer();
=
and/or

// registers a buffer (UB to acc= ess or deallocate after registering)
<= /span>void std= ::set_o= om_buffer(void *buffer, std:= :size_t n) noexcept;

The buffer may be used by the construct= or of `std::exception` and subclasses, and to construct other implementation (or user?)-defin= ed objects, in the event that normal allocation fails.

=
This has the advantage of (mostly) maintaining the "you don't= pay for what you don't use" principle, is relatively easy to impl= ement and wouldn't alter the semantics of existing programs.
<= div>
-Ray

Pro= blem is that in this case I need to correctly pre-calculate my 'excepti= on memory' requirements for my program to be reliable. What is proposed= is to have a universal solution... which can be a "safety net" f= or your proposal in case if buffer is too small or program is written in su= ch way that these requirements aren't bounded.

=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/25f81ffc-011d-4ba3-9eac-5e130638a03a= %40isocpp.org.
------=_Part_2106_792816165.1503626546212-- ------=_Part_2105_1915166498.1503626546212-- .