Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107497 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62301 invoked from network); 11 Oct 2019 13:22:12 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 11 Oct 2019 13:22:12 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 105E62D202F for ; Fri, 11 Oct 2019 04:05:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: X-Spam-Virus: No Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Fri, 11 Oct 2019 04:05:19 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id n14so9374159ljj.10 for ; Fri, 11 Oct 2019 04:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wrhF1iPhVUOx62iw/Rp8iX3lrRu86HEXQkm7Ha/N+uM=; b=PG02mYlptRGuwScBBxy+2hNcSpXmWzD9bQ1IPALCWuNN/SD0/hwIfXhfQU3BKYf7Kl imqsI1R2B3XYt9718/XS4LD0Zm9dc5j7+X+TvYTJj9XG7q2gkJ60SRQjoklpBFr349vN kn6rn+zLYBjM+L9pWKtUZaSYvLopBUFUMW0k0o45oEbvSI6tomQFcNcQ8BLetK6o3YMT 8jiI7d5fnYJ3tx0+6l1u70/4rsrK1db9DhfLy6oDDJDXJjm8EMS5oeaTY3fgHgVMfq3m 5h7ljErCxc+Im76EwAB/wQlFDR3cvcH8BhVVtVagtjsDMYjMswkSxgydpwZne/wLdum+ H7kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wrhF1iPhVUOx62iw/Rp8iX3lrRu86HEXQkm7Ha/N+uM=; b=QyEEY0upUNkPAvgsqmWE+48UWdpk9T2WjYYq93D3SxlWTJnYckNu5U0euN5tvsAhi/ SHdg6nCBr+1CPYjpFWW4XAUMY9ECuRHstg3+xomkad4/l4Z/OZci366v6igop+VI5mnp 2RBN7PwLin4s4PQOWWRWF47E5ktc8bMBYkJLTQJo7FwjubIOJREIJI0ZfrcvTHeEwPIG 7RDgUNq33iQmy0DP1tUidiLEU/zG8lWUnXKHGbbd2sogX4lpDkgNUYQHXLCF17beR2fo 0U/fYd90jyUXDNHxUX9+yiSjCNXN3E9DY0KJjdsi2UfLY8QA0ctk3Z9wGoPgC7KYG3Up zabw== X-Gm-Message-State: APjAAAUtdtNA7ljvVtu97adSFF7qnJ53OYr0IKJMfe5vF79UaH24RKO6 Jl/z2CB1mSukFNEZ5uPGFLe4vj4jZnUBMXyvWMLSA+FtsCA= X-Google-Smtp-Source: APXvYqxpbPeeAZINyh6SCC41rbagaQmp3PW6kjnFg8qCoFDnBe2GwChAbRLv/+FkUlAWDFh61o7D2e8C5rdaMM/kGzw= X-Received: by 2002:a2e:7a18:: with SMTP id v24mr9025872ljc.52.1570791917711; Fri, 11 Oct 2019 04:05:17 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 11 Oct 2019 13:05:01 +0200 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000004574d50594a07e3f" X-Envelope-From: Subject: exit() via exception From: nikita.ppv@gmail.com (Nikita Popov) --0000000000004574d50594a07e3f Content-Type: text/plain; charset="UTF-8" Hi, Currently exit() is implemented using bailout and unclean shutdown, which means that we're going to perform a longjmp back to the top-level scope and let the memory manager clean up all the memory it knows about. Anything not allocated using ZMM is going to leak persistently. For me, one of the most annoying things about this is that we can't perform proper leak checks on code using PhpUnit, because it will always exit() at the end, which will result in "expected" memory leaks. I think it would be good to switch exit() to work by throwing a magic exception, similar to what Python does. This would allow us to properly unwind the stack, executing finally blocks (which are currently skipped) and perform a clean engine shutdown. Depending on the implementation, we could also allow code to actually catch this exception, which may be useful for testing scenarios, as well as long-running daemons. I'm mainly wondering how exactly we'd go about integrating this in the existing exception hierarchy. Assuming that it is desirable to allow people to actually catch this exception, my first thought would be along these lines: Throwable (convert to abstract class) \-> Exception \-> Error \-> ExitThrowable This does mean though that existing code using catch(Throwable) is going to catch exit()s as well. This can be avoided by introducing *yet another* super-class/interface above Throwable, which is something I'd rather avoid. Anyone have thoughts on this matter? Nikita --0000000000004574d50594a07e3f--