220 39326 <4ac80882-16fc-4ab4-9a12-64da1ef0e974@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Mon, 23 Jul 2018 21:43:57 -0700 (PDT) Lines: 78 Approved: news@gmane.org Message-ID: <4ac80882-16fc-4ab4-9a12-64da1ef0e974@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <1c229827-6d5d-45bd-8766-c3af818b2b0b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3648_525886493.1532407437861" X-Trace: blaine.gmane.org 1532407313 9167 195.159.176.226 (24 Jul 2018 04:41:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2018 04:41:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDW53LNAKGQEIX4EMVQ@isocpp.org Tue Jul 24 06:41:49 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhp8v-0002H5-3L for gclcip-std-proposals@m.gmane.org; Tue, 24 Jul 2018 06:41:49 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id b12-v6sf1475210ybr.12 for ; Mon, 23 Jul 2018 21:44:00 -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=u8CT6pcARyynu5oTkCrBzf58XMDzhgS8RCLFiZEI+ME=; b=fusxGUbfTV+3HWqcpq81xwCvQsNsgiFAH9wII0KKAZ9A6efvH+vC6Q3JPlBPstN3UT 37UGMkIjvkE6KEQbIg/uNOz38dSQ10ek9a8MI1Y/FeiDL/SGXPWJMzXKVBY8NCHgUzic n2tXNzzyPdzCG0OD2HUK9l7fUa3GiGIDq0dtGE+0vD5EhfSU/fJtPFVxQIwX/8OkGs6O trTMaUVa4bZApeQ6iOyghdLgVmF6mcePJy+kXYHBZ0EO5Rjc0FDszORnOTg+G3Uj1g5L HPWMn3ee/ksO+IjWSlmGwXI7uGlH6E4cT4aikcR7uuNeZDqQdCoIdijrhi6i4qjSQoTf vpvg== 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=u8CT6pcARyynu5oTkCrBzf58XMDzhgS8RCLFiZEI+ME=; b=itsc1yb7rdI25MmgkGaBq9K6rzH5U47VglDyC5sqyGpOyNYklaZMk4RYh4TGUcdvrN snIKzlnb+bdH0dRrqbDZrItwna4jbKtoOzfRqbPiY2PG4KhkjClBEgfO816MlkUZKogl jdEkciVQh1bNnwRsVIC3gXVDtX8b5x8LIMDf4By6gdKju4fVhCH+/QW+cKBkZZRRS/QR 2MaDT9vthOAs6bJnoyF2nnqr5Ao1RkLt6HxI6153e/VV+m0OC4gnJmJ1w61cKgybxG5y 1BQ4dnTWQTxTBzc/ovhIwK8dBVd3KTJWMc8Grs91KCqAwx3LALdrvJMfLu1TdmQ1V6FY SnJw== 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=u8CT6pcARyynu5oTkCrBzf58XMDzhgS8RCLFiZEI+ME=; b=ap7S/CcICYG72zcbfWeCxEjJszkxzQ27AsahS6xiuUHNguRj/dXikQEOHQo8LCRVyP svcn7rAAAHdlmBrpWSCSxP0ab5zCnHkrtMLxRLo9GUYNAWGqNjWrpCtKng9IOUBaSl/3 T4OrD7XWlUOTEGdBmz1OJX+C7QQ+f28mo+QRLEjGawMycNWBe2thJ59CZusQoCSWV7+q 2VJGdRhH0BYZvvXQuOTtaJXy10g0rPWtNeFUi2PEv1qJJ2x7Sb9czi4Y7cst/xfhObBi cnm1B0mJU2JaytpCXydtqTx8PYre61Wap+84Tkw0hvezTfkVMQ1VPih9MnoBmGrRLcA5 ofqw== X-Gm-Message-State: AOUpUlHvfwHVqQU1TU1gM+AE9ptJzalRnEV99l8hVnZOHZ1hWRWwZobE YsxTppFV+LzU4n0x29IV3QxoAg== X-Google-Smtp-Source: AAOMgpe7uAm54gcJImTmcck6dXlaehP9YjLheG3a+ZozDje3CVGYOUeA4iuiKDmHGT2iqj1XYvzXPA== X-Received: by 2002:a81:6246:: with SMTP id w67-v6mr4508627ywb.145.1532407439707; Mon, 23 Jul 2018 21:43:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2fd2:: with SMTP id v201-v6ls2446218ybv.10.gmail; Mon, 23 Jul 2018 21:43:58 -0700 (PDT) X-Received: by 2002:a25:8203:: with SMTP id q3-v6mr264262ybk.1.1532407438285; Mon, 23 Jul 2018 21:43:58 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39326 Archived-At: ------=_Part_3648_525886493.1532407437861 Content-Type: multipart/alternative; boundary="----=_Part_3649_1482762122.1532407437861" ------=_Part_3649_1482762122.1532407437861 Content-Type: text/plain; charset="UTF-8" On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinstall wrote: > > Error handling via an effective static state isn't thread safe. Marking > the flag as volatile and telling users to check for errors immediately > after the function call goes some way to help, I guess, but it's not > sufficient to guarantee that errors won't crop up in the wrong thread (or > do I have some reading to do?) > I think this is a misunderstanding of what the paper is saying. It is not talking about "static state" (even though it appears to). The `funcName.failed` bit is not intended to be a static property of `funcName`; it's closer to an invisible stack variable, which you access by using the function's name. The compiler turns "funcName.failed" into the specific stack location or register or whatever that maps to that data. Everything is on the stack, so nothing from other threads can influence this one. That is, two functions in two threads that both call `funcName` and attempt to access `funcName.failed` will be accessing stack data/registers, not static data. -- 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 email 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/4ac80882-16fc-4ab4-9a12-64da1ef0e974%40isocpp.org. ------=_Part_3649_1482762122.1532407437861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinst= all wrote:
Error handling via an effect= ive static state isn't thread safe. Marking the flag as volatile and te= lling users to check for errors immediately after the function call goes so= me way to help, I guess, but it's not sufficient to guarantee that erro= rs won't crop up in the wrong thread (or do I have some reading to do?)=

I think this is a = misunderstanding of what the paper is saying. It is not talking about "= ;static state" (even though it appears to). The `funcName.failed` bit = is not intended to be a static property of `funcName`; it's closer to a= n invisible stack variable, which you access by using the function's na= me. The compiler turns "funcName.failed" into the specific stack = location or register or whatever that maps to that data.

=
Everything is on the stack, so nothing from other threads can in= fluence this one. That is, two functions in two threads that both call `fun= cName` and attempt to access `funcName.failed` will be accessing stack data= /registers, not static data.

--
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/4ac80882-16fc-4ab4-9a12-64da1ef0e974= %40isocpp.org.
------=_Part_3649_1482762122.1532407437861-- ------=_Part_3648_525886493.1532407437861-- .