Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80145 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85894 invoked from network); 4 Jan 2015 13:00:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2015 13:00:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=kontakt@beberlei.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=kontakt@beberlei.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.176 cause and error) X-PHP-List-Original-Sender: kontakt@beberlei.de X-Host-Fingerprint: 74.125.82.176 mail-we0-f176.google.com Received: from [74.125.82.176] ([74.125.82.176:35340] helo=mail-we0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 40/C0-15455-88939A45 for ; Sun, 04 Jan 2015 08:00:57 -0500 Received: by mail-we0-f176.google.com with SMTP id w61so6486578wes.7 for ; Sun, 04 Jan 2015 05:00:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F0MlRfXKZShZWPXZF69l1tLCu5BmL9yA/Vndl2jC/DM=; b=Sg7qSjma8SEi9X5ECZrBpCjHfM5tXnnnKn0WWmVI7HfAM0eqV3322RrgnLyNoAcyZX rf5KDIrTQTss5Yu5h4l0/irWM+FVFs+t3QU3wGH/bWRzNEmJmUOqrMncxYwNDcY0OAaY ypKbvsMcSk8a16Px/NLHZ//feUdlYlOI1Gg7/8vz9h/t3vn0iiXCGjMpc36QHx0SvN9f iA3fdCriHcbOLyRLqbzz045RUPhg21za8DJHcfMwtDLB05czljrrLy3NyaKCgf15Okii lPEmZvD8rp46Ikgu3/HNnxPEnF/fzKhKSD421376MIuIJE7ObinGWALu3C7sJiZ72DTp doCg== X-Gm-Message-State: ALoCoQn59G40oKNBpr1XV1qPR9lCzfv9hBMDBFHcJYGGZm/EF4cmXgPh00zJKiue6tArLbvexBqm MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr170491048wjc.110.1420376452633; Sun, 04 Jan 2015 05:00:52 -0800 (PST) Received: by 10.194.57.73 with HTTP; Sun, 4 Jan 2015 05:00:52 -0800 (PST) X-Originating-IP: [77.11.123.69] In-Reply-To: <002d01d0281b$1e775730$5b660590$@tekwire.net> References: <002d01d0281b$1e775730$5b660590$@tekwire.net> Date: Sun, 4 Jan 2015 14:00:52 +0100 Message-ID: To: francois@tekwire.net Cc: PHP Internals Content-Type: multipart/alternative; boundary=047d7bb70bb2e831f5050bd329e2 Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files From: kontakt@beberlei.de (Benjamin Eberlei) --047d7bb70bb2e831f5050bd329e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 4, 2015 at 1:36 PM, Fran=C3=A7ois Laupretre wrote: > > De : Benjamin Eberlei [mailto:kontakt@beberlei.de] > > I want to open discussion on my RFC to strengthen the ability of > extensions > > to provide functionality to developers in both C **and** PHP code. > > > > For this extensions can add PHP files to a list of "prepend files" that > are > > part of every request execution exactly the same way the INI > > auto_prepend_file functionality works: > > > > https://wiki.php.net/rfc/extension_prepend_files > > > > I propose implementation details in the RFC, but they are completely up > to > > discussion. I am even sure there is probably a better way than what I > > proposed, because I am not familiar with the code. > > Can you please develop the API changes in your RFC ? You're talking about > changes in zend_execute_scripts(), a new zend_execute_script() function > (but the name in the prototype is wrong), then php_execute_scripts()... > Fixed the typo in zend_execute_script. The API of php_execute_scripts doesnt change, only the implementation. > > Where are the file handles coming from ? Does it mean that the files to > prepend will be kept open ? > File handles have existed before in php_execute_scripts, they were passed via the va_list into zend_execute_scripts. > > Do you register paths to prepend, or will the scripts be loaded in memory > during MINIT ? > You register file paths to prepend. > > How will these files be cached by opcode caches (mandatory for such a > feature) ? > Files will be cached, because opcache hooks into zend_compile_file, which is used downstream of zend_execute_scripts. That means the feature would autoamtically use and work with opcache. > > And, finally, how can an extension determine where a given PHP script it > requires has been installed ? It makes sense in php.ini because it is und= er > control of the final user. But an extension is just a C library, installe= d > anywhere or bundled in the PHP executable. Would it compute the script > paths from PHP installation paths ? > Files must be either in the PHP include path, or via absolute path, for example by putting them right next to the shared object (.so) files and using the extension_dir path inside the code, see the following for an example (a hacked approach): https://github.com/QafooLabs/php-profiler-extension/blob/master/qafooprofil= er.c#L744 > Actually, I don't see how it would work with PHP scripts which would > remain separate from the extension code. What I would imagine for such a > feature, would be PHP code embedded in the extension as a memory buffer, > registered during MINIT, and then executed at each RINIT. This would > probably require a stream wrapper because the opcode cache would require > paths for this code. We can also concatenate the scripts but we still nee= d > a virtual path. The stream wrapper would just be simpler to implement. > This uses the usual "require" functionality that you can call from PHP as well. If the files are not found, then you get an error. > > Regards > > Fran=C3=A7ois > > --047d7bb70bb2e831f5050bd329e2--