From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Dec 7 21:35:54 2014 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 4816C3586E3; Sun, 7 Dec 2014 21:35:54 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by www.open-std.org (Postfix) with ESMTP id 05A5C358488 for ; Sun, 7 Dec 2014 21:35:47 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39322) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1XxiYV-0005MH-X7 (Exim 4.82_3-c0e5623) for sc22wg5@open-std.org (return-path ); Sun, 07 Dec 2014 20:35:47 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1XxiYV-0007JP-4u (Exim 4.72) for sc22wg5@open-std.org (return-path ); Sun, 07 Dec 2014 20:35:47 +0000 Received: from [80.189.200.45] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 07 Dec 2014 20:35:47 +0000 Date: 07 Dec 2014 20:35:47 +0000 From: "N.M. Maclaren" To: WG5 List Subject: Re: [ukfortran] (SC22WG5.5385) (j3.2006) Straw vote on draft DTS Message-ID: In-Reply-To: <20141207195158.20EE0358488@www.open-std.org> References: <20141108182113.6EC5E3581CE@www.open-std.org> <20141207195158.20EE0358488@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Dec 7 2014, Bill Long wrote: > > There is substantial opinion that implementing stalled image recovery is > not easy. I do not disagree. In simplest terms, it is equivalent to > implementing the infrastructure to handle an exception handling > mechanism. It is a bit simpler - the handler is basically internal to the > runtime rather than user-specified, and if the relevant END TEAM > statement lacks a STAT= specifier, the code would end up aborting anyway, > so there is no need to do much before then. However, the basic process of > unwinding the call stack (if there is one) that grew after the CHANGE > TEAM statement execution is more or less the same as for an exception > handler. Given that exception handlers already exist in other languages, > and certainly at the system level, the argument that implementors do not > know how to do this seems weak at best. I understand grumbling about hard > work, not claims of inability. I do not intend to start a debate on this matter, but need to correct the above. Yes, it is equivalent to exception handling (with the extra complications of parallel data access), but for the case of system- generated exceptions and the consequent undefined behaviour. And it is that which has been tackled many times over the past half-century, has failed in every case I have seen, and where my experience lay. Recovering from 'clean' exceptions caused by an explicit, programmed raise/throw/etc. statement are trivial by comparison, and it is only those that have been specified in any language or environment that I have ever seen. Certainly including C, C++, Ada and Python - and, for that matter, all of the operating system exception handling interfaces that I have seen. In all other cases, they have specified the API (i.e. the syntax) and left the semantics undefined. If there is ANY example of specifying recovery from general, system generated exceptions of the sort that trigger undefined behaviour, I have never seen it. Regards, Nick Maclaren.