> I was waiting after Rasmus said he wanted to compare to the internal > Signals code they have at Yahoo before asking againd about inclusion. > Gopal is familiar with the Yahoo code as well and we're planning to > get together tomorrow and to review and make sure there aren't any > critial oversights on this implementation. If the timeline allows 5.3 > would be great but we may want to wait until Friday to commit.
Discussed this a bit with Rasmus and Gopal yesterday. There are a couple scenarios that do need to be addressed however since having this is still an improvement over not, the thought was to commit and apply fixes shortly either in 5.3 or whatever comes afterwards. The biggest concern is the usage of a linked list in the default handler. If the handler is invoked within an alloc, appending to the ll will cause a recursive alloc. I added queuing of the deferred signals recently after originally using a static table but it seems the latter will be more stable and queuing is probably not so important. I can revert back to using a static table quickly, either in the initial patch, depends on who commits how fast, or as a new patch against 5.3 after the original is committed since I have no karma. Another thought was to add a check in rshutdown to determine if an extension had replaced the default zend handler that is setup in rinit. This could be useful for debugging and I assume we would want to trigger a E_CORE_WARNING with hopefully enough information to know which extension it was. Probably don't need this right away though. -lucas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
