On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon <poll...@php.net> 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
