Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103067 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11369 invoked from network); 8 Aug 2018 21:10:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Aug 2018 21:10:11 -0000 Authentication-Results: pb1.pair.com header.from=nicolai.scheer@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=nicolai.scheer@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.68 as permitted sender) X-PHP-List-Original-Sender: nicolai.scheer@gmail.com X-Host-Fingerprint: 209.85.214.68 mail-it0-f68.google.com Received: from [209.85.214.68] ([209.85.214.68:36836] helo=mail-it0-f68.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/99-18754-23C5B6B5 for ; Wed, 08 Aug 2018 17:10:10 -0400 Received: by mail-it0-f68.google.com with SMTP id p81-v6so5608122itp.1 for ; Wed, 08 Aug 2018 14:10:10 -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=DSYHZUDqFu3jQiSDuU4couXuME6uzhuZ+JnVoki9P24=; b=dabninIMwmUqceoJli/3wERD/JbndKuMFi1FZp9kwINLM3jZ2zd9xBYVlrOVfkQ8ss sk/lw+k0LwpLApE5sXE8ZgyisAwDKn31oU7T377UknMWD1bQ+CMS+WPIT+Cgs0UoneKr CKTlIPGZYNRT0H5s0n7sMxfxMQX7OwQHY2te4DmTDuCPTTsr3i5nLsWtD0zSLNwtVFvQ 7oSOh0kTXd6nVFogobj/3dOpiinHz4oM5M7KsbWEBKZ//7ak+VJaFK2L1wY+OcgXgCsC Z4qzCWOcXHr/Es259LhVq/Dr9ZJPoOrswUUn/0tefroHaeo5PzBaahsZ3M6L0yKNGHnF Ctjw== 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=DSYHZUDqFu3jQiSDuU4couXuME6uzhuZ+JnVoki9P24=; b=Ox2mlD6JQ2H+LXg6aErrLVz7MFGFHXfeJQkV8aDxBnk0/s2jVOQSqqDnIsD3q5QXAx t0WU7vHinHWo4wY6CWxXLT/k5jMpjxmz97sMM5ADau/zQMJdGEF3dvdogc4y3b20brN4 StLzFCB8iRwFxgcROCEffDGPygM+8HuOaFgv/lDQHI6YZSdtwUg7kgf5GEdrYCONU5zv FHnv+V/cwc1ZQhTkZedEW4Jc6c1PB3C18Ho/6HbCnO8ZC1nNwRpkPzTQ6iiG8VhXx71/ GMbJbWEw5V9acsZ4l5IUc43M8XW+fHZiTWYFkLVM5/A2+NRkY7O49EvL18MWRvU4AmxK OJ+g== X-Gm-Message-State: AOUpUlE8II19iT+4vNZvAyZdYZT3D0CO4lqMk82ECvMVHHuf+uO7l74Q 0P2U72IJW+H3Sby0FbSi6zZT5HFzA1w+mAgk1ov6XCmu X-Google-Smtp-Source: AA+uWPxxVQd5M9K1gQZZro7zofKPC3//c3y3FO2SkTqSt9G43RPpjLj7AK6lflJzaoz+eJDC4Yr1m6wy3YubLZZ7HF0= X-Received: by 2002:a02:952a:: with SMTP id y39-v6mr4120874jah.60.1533762607974; Wed, 08 Aug 2018 14:10:07 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 8 Aug 2018 23:09:55 +0200 Message-ID: To: PHP Internals Content-Type: multipart/alternative; boundary="0000000000006b10360572f2ef41" Subject: object destruction php 5.6 vs. 7.2 From: nicolai.scheer@gmail.com (Nicolai Scheer) --0000000000006b10360572f2ef41 Content-Type: text/plain; charset="UTF-8" Hi, I'm currently facing difficulties to migrate one of our extension from php 5.6 to 7.2. Basically everything works fine. The extension defines its own resource, and since it's object oriented, stores the resource inside a member variable, i.e. we register the custom resource using zend_list_insert followed by calling zend_update_property. Every method then fetches the resource using zend_read_property and zend_fetch_resource. The resource itself has a dtor, which is registered through zend_register_list_destructors_ex. The class itself does not have a __destruct method. Using php 5.6, when unsetting the object in userspace the resource dtor was called immediately. In php 7.2 this does not seem to be the case anymore - i.e. I see that the resource dtor is called at script end, but not when unsetting the object in userspace. This results in php holding a lot of connections (that's what the resource is about) up to the point where no new connection can be created (which is bad). I implemented and registered a __destruct method for testing purposes - this one indeed gets called on object destruction triggered by unsetting the variable in userspace. So my question here ist: Can anyone give me an insight what is happening here? I know, I posted not quite much information, but there must be something fundamental I'm missing. Basically I would expect, even if I do not implement a custom __destruct method, that upon object deletion all members variables are deleted as well - this would include the resource, and as such, the resource destructor would be called. That seems to be what is happening in php 5.6 but does not work in 7.2 anymore. Of course I could move the code from the resource dtor to a __destruct method - but what's the point in providing a resource destructor then (in my case)? What is the correct way for a class to hold a (protected) resource and make sure that resource gets destroyed correctly upon object deletion? Thanks for your help! Greetings Nico --0000000000006b10360572f2ef41--