PHP_FCGI_CHILDREN number of children processes will be spawned, sharing
same TCP socket. To implement yet
- children cleanup on exit
- automatic children re-spawning
If CGI TS build is used, and there are some hard errors (fe missing
dependency .dll or .so), the core will want to log it. The CGI
log function will want to check whether fcgi_logging is enabled. But,
if this kind of error happens in the extension register phase,
MINIT for the CGI module is most likely wasn't run yet (startup phase).
That will result in accessing uninitialized globals and a crash.
Previously fcgi_request defined in main/fastcgi.h might be treated differently in different files, because of different behavior of #ifdef TCP_NODELAY. This leaded to stack memory corruption and unpredictable crashes.
* pull-request/1284:
Rename interface macros
Fix typo in UPGRADING
Move definition of Throwable to zend_exceptions.h/c
Check for zend_ce_throwable instead
Fix some missed tests
Add Throwable tests
Fix previous exception type check
Updated UPGRADING with RFC link
Changed AssertionException to AssertionError
Update exception error messages
Throwable method signatures.
Update exception names in tests after formatting changes.
Merge exception formatting changes.
Make zend_get_exception_base static.
Fix a few missed tests.
Fix handler double copy.
Updated tests to reflect exception class changes.
Remodel exceptions based on Throwable interface
This is yet a workaround, if another part of the source would need
the same object file, it'll end up producing duplicated nmake target.
Some additional implementation is needed so same object files can be
shared between different modules, to handle this situation better.
This implements a reduced variant of #1226 with just the following
change:
-Fatal error: Uncaught exception 'EngineException' with message 'Call to private method foo::bar() from context ''' in %s:%d
+Fatal error: Uncaught EngineException: Call to private method foo::bar() from context '' in %s:%d
The '' wrapper around messages is very weird if the exception
message itself contains ''. Futhermore having the message wrapped
in '' doesn't work for the "and defined" suffix of
TypeExceptions.
TypeException stays as-is for now because it uses messages that are
incompatible with the way exception messages are displayed.
closure_038.phpt and a few others now show that we're generating
too many exceptions for compound operations on undefined properties
-- this needs to be fixed in a followup.
