Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
Right, gotcha. I think ideally someone should put in the grunt work to do what you suggested: Build libphp5.so all the time, then link up php/ mod_php5.so/etc... against that as a shared system library (which in turn other programs or SAPIs could link against). I'm not sure if anyone has the time and patience to do that (for its relatively small return), but it'd get my vote. If nothing else, nice poetry selections. -Sara On Fri, Aug 16, 2013 at 5:14 PM, J David wrote: > To try it out, here's a hacky little Makefile you can use to build the > CLI SAPI against the null shlib: > > http://pastebin.com/3FxWhZn4 > > Resulting in: > > $ ls -l phpn > -rwxrwxr-x 1 me staff 113669 Aug 17 00:13 phpn > $ ldd phpn > phpn: > libphp5.so => /usr/local/php/5.6-dev/lib/libphp5.so (0x2808) > libc.so.7 => /lib/libc.so.7 (0x28487000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x285ab000) > libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x285ce000) > librt.so.1 => /usr/lib/librt.so.1 (0x28633000) > libm.so.5 => /lib/libm.so.5 (0x28639000) > libthr.so.3 => /lib/libthr.so.3 (0x28653000) > libz.so.6 => /lib/libz.so.6 (0x28673000) > libssl.so.8 => /usr/local/lib/libssl.so.8 (0x28687000) > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x286e1000) > libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x2885e000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2898c000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28a84000) > $ ./phpn -v > PHP 5.6.0-dev (cli) (built: Aug 17 2013 00:06:53) > Copyright (c) 1997-2013 The PHP Group > Zend Engine v2.6.0-dev, Copyright (c) 1998-2013 Zend Technologies > > Thanks! >
[PHP-DEV] Announcements for PHP 5.4.18 and 5.5.2
Did I overlook the announcements for 5.4.18 & 5.5.2? Or aren't they posted to this list anymore? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Module shutdown order again
Looking at https://bugs.php.net/bug.php?id=65463 My brain is foggy on why we call zend_destroy_modules() before zend_hash_destroy(GLOBAL_CLASS_TABLE) in zend_shutdown(). Anyone remember the reason? I have verified the issue described in 65463. On a SIGTERM to Apache mid-request, the extension ends up getting unloaded before the global class table is destroyed causing the segfault described in the bug. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
On Fri, 2013-08-16 at 12:36 -0400, J David wrote: > Our solution was to develop a new pseudo-SAPI we call the null SAPI. > All it does is build a complete libphp5.so with no SAPI-related > structures or functions in it at all. Then we can build our real > embedded SAPI -- with all its extra dependencies and goofy custom I/O > handling -- outside the PHP tree and just link to the shared library, > rather than entangling our app's source tree and the PHP source tree. I was successful by using embedded SAPI for that and ignoring all things from php_embed.[ch]. Sure this gives few extra symbols and a few bytes of unneeded code but works fine. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Module shutdown order again
Rasmus Lerdorf in php.internals (Sat, 17 Aug 2013 07:37:30 -0400): >Looking at https://bugs.php.net/bug.php?id=65463 When I saw the subject, I was reminded of https://bugs.php.net/bug.php?id=65338 That was another case of unorderly unloading modules. I thought it was a bug in zend_string.c, but Dmitry solved it by patching opcache. Disregard this message if it is not related at all. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
On Fri, Aug 16, 2013 at 5:28 PM, Sara Golemon wrote: > Ah, I see. I wasn't taking "null" quite literally enough. :) > > That sounds pretty awesome to me. Assuming the implementation looks good > you'd get my vote. "Implementation" might be a little generous… it's a config.m4 file, a header file designed to be included by the real SAPI and s some other header files, and an empty source file. But you're most welcome to look at it: http://pastebin.com/ZfxY0nMV Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
To try it out, here's a hacky little Makefile you can use to build the CLI SAPI against the null shlib: http://pastebin.com/3FxWhZn4 Resulting in: $ ls -l phpn -rwxrwxr-x 1 me staff 113669 Aug 17 00:13 phpn $ ldd phpn phpn: libphp5.so => /usr/local/php/5.6-dev/lib/libphp5.so (0x2808) libc.so.7 => /lib/libc.so.7 (0x28487000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x285ab000) libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x285ce000) librt.so.1 => /usr/lib/librt.so.1 (0x28633000) libm.so.5 => /lib/libm.so.5 (0x28639000) libthr.so.3 => /lib/libthr.so.3 (0x28653000) libz.so.6 => /lib/libz.so.6 (0x28673000) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x28687000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x286e1000) libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x2885e000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2898c000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28a84000) $ ./phpn -v PHP 5.6.0-dev (cli) (built: Aug 17 2013 00:06:53) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.6.0-dev, Copyright (c) 1998-2013 Zend Technologies Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
On Fri, Aug 16, 2013 at 12:55 PM, Johannes Schlüter wrote: > I was successful by using embedded SAPI for that and ignoring all things > from php_embed.[ch]. Sure this gives few extra symbols and a few bytes > of unneeded code but works fine. Yes, exactly. This is a cleaner/more formal way of doing that, without the extra symbols and unneeded code. This is a small change that is no trouble to keep on our local branch. My question is basically whether it's of value to anyone but us and "no" is a perfectly valid answer. :) Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon wrote: > Apart from managing lifecycles, the SAPI is also resposible for things like > directing I/O between the host application, how does null-sapi handle this? It doesn't. It provides no SAPI functionality at all (hence "null"). Its only purpose is to allow building SAPIs separately from building PHP by leaving all that stuff out. The sapi_module_struct and all its callbacks -- including but not limited to I/O handling -- are provided later by the externally-built SAPI. This offers several benefits: - it makes embedding PHP easier and more flexible. - it allows new SAPIs to be developed and distributed independently of the PHP source tree (i.e. as part of a web server or as a separate package) - it (hypothetically) makes SAPIs modular and able to be selected at runtime rather than build time - (therefore) it allows multiple SAPIs to coexist in a single installation Obviously our use case is the first/second. The last two benefits are hypothetical, since they would require existing SAPIs to be tweaked. E.g. currently the CLI SAPI and the apache2 SAPI can coexist, but they do so by building the entire PHP runtime into both …/bin/php and …/apache/libexec/mod_php5.so. If they were tweaked to build with null-sapi: - the "main" build would be null-sapi which produces only libphp5.so with no SAPI code - the CLI and apache2handler SAPI's would be built after/separately from the "main" build, like extensions - the CLI binary and mod_php5.so would both link to the same shared libphp5.so at runtime, instead of the current approach where they both contain the entirety of PHP. Modifying the existing SAPI's would be a bigger step and may not be desirable for other reasons. It isn't something we have pursued or consider necessary; the first two benefits were sufficient for us to justify doing this. But the issue of building multiple competing SAPIs from one tree does come up from time to time, so if you want to, imagine a possible bright future world of arbitrary happily coexisting SAPIs. :) Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
Ah, I see. I wasn't taking "null" quite literally enough. :) That sounds pretty awesome to me. Assuming the implementation looks good you'd get my vote. On Fri, Aug 16, 2013 at 11:03 AM, J David wrote: > On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon wrote: > > Apart from managing lifecycles, the SAPI is also resposible for things > like > > directing I/O between the host application, how does null-sapi handle > this? > > It doesn't. It provides no SAPI functionality at all (hence "null"). > > Its only purpose is to allow building SAPIs separately from building > PHP by leaving all that stuff out. The sapi_module_struct and all its > callbacks -- including but not limited to I/O handling -- are provided > later by the externally-built SAPI. > > This offers several benefits: > - it makes embedding PHP easier and more flexible. > - it allows new SAPIs to be developed and distributed independently of > the PHP source tree (i.e. as part of a web server or as a separate > package) > - it (hypothetically) makes SAPIs modular and able to be selected at > runtime rather than build time > - (therefore) it allows multiple SAPIs to coexist in a single installation > > Obviously our use case is the first/second. > > The last two benefits are hypothetical, since they would require > existing SAPIs to be tweaked. > > E.g. currently the CLI SAPI and the apache2 SAPI can coexist, but they > do so by building the entire PHP runtime into both …/bin/php and > …/apache/libexec/mod_php5.so. If they were tweaked to build with > null-sapi: > > - the "main" build would be null-sapi which produces only libphp5.so > with no SAPI code > - the CLI and apache2handler SAPI's would be built after/separately > from the "main" build, like extensions > - the CLI binary and mod_php5.so would both link to the same shared > libphp5.so at runtime, instead of the current approach where they both > contain the entirety of PHP. > > Modifying the existing SAPI's would be a bigger step and may not be > desirable for other reasons. It isn't something we have pursued or > consider necessary; the first two benefits were sufficient for us to > justify doing this. But the issue of building multiple competing > SAPIs from one tree does come up from time to time, so if you want to, > imagine a possible bright future world of arbitrary happily coexisting > SAPIs. :) > > Thanks! >
[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
Hi Mike, On Mon, Aug 12, 2013 at 4:19 AM, Michael Wallner wrote: > On a side note: all these tests pass for me on Linux/gcc and > FreeBSD/clang, yet I'm still working on a Solaris/SunC build > environment. > I've got errors, but I don't have problem now. I didn't look into the test log files, so I cannot tell what was wrong. Test w/o valgrind failed and valgrind reported errors. I needed full rebuild with vcsclean, perhaps? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
