On Fri, 2014-11-21 at 23:06 +0400, Tigran Bayburtsyan wrote:
>
> And based on that now my main problem is that in PHP C++ sources there
> are a lot of static, global variables which is not useful for me, to
> clean that all for every request .... So I'm wondering to build
> something which will help to somehow "save current state" of PHP
> SAPI , and continue it on every request from saved source, without
> sharing any variable between multiple requests.
If you need to cleanup things between requests php_request_[startup|
shutdown] are the functions you need which will do that.
Basic flow in pseudocode with reference to pconn functions doing a bit
more:
/* once on application start, see also pconn_init_php() */
sapi_startup();
/* for each request, see pconn_do_request() */
while (!program_end()) {
/* start request context */
php_request_startup(TSRMLS_C);
/* we can multiple scripts in one request context */
while (get_script_for_current_request()) {
if (source_is_in_a_file()) {
php_execute_script(file_handle TSRMLS_CC);
} else if (source_is_in_a_string()) {
zend_eval_String();
}
}
/* clean up everything related to the request */
php_request_shutdown((void *) 0);
}
/* at the end of the application shutdown completely */
php_module_shutdown(TSRMLS_C);
sapi_shutdown();
Now this uses global state. If you need multiple states parallel compile
PHP in threaded mode (--enable-maintainer-zts manually at config time or
force it by PHP_BUILD_THREAD_SAFE in your SAPI's custom config.m4. In
that mode PHP globals which are request-specific (i.e. everything that
happens in the while (!program_end()) loop) are bound to a windows
thread or pthread (depending on platform). So if your event based system
needs multiple PHP requests in parallel it has to create enough threads
and route PHP work there. Handling multiple requests from a single
thread in parallel is not supported from PHP's architecture (if you like
adventures you might try to hack this by looking at tsrm_thread_id in
TSRM/TSRM.c but that's not really a good way.
Another approach is not embedding PHP directly in your process (which is
dangerous anyways - PHP might crash due to stack overflow on some
recursion patterns etc. which would kill your complete server) but by
calling external PHP processes via FastCGI or FPM protocols, just like
nginx or others do.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
