# [RFC] Zend Signal Handling - Thread: https://externals.io/message/38794 - Original archive: https://news-web.php.net/php.internals/38794 - Started by Lucas Nealan on 2008-07-06T18:56:32+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38794 — Lucas Nealan — 2008-07-06T18:56:32+00:00 URL: https://externals.io/message/38794#38794 Hi Internals, I am proposing the following RFC to improve signal handling in the Zend Engine: http://wiki.php.net/rfc/zendsignals The purpose of zend internal deferred signal handling is to improve the stability of PHP and extensions when running under any forking SAPI. Additionally heavy users of APC or other bytecode caches under Apache 1.x may also see a performance improvement. Please see follow the link above to the complete RFC for details. I look forward to hearing feedback. -lucas --- ## #38801 — Dmitry Stogov — 2008-07-07T07:17:37+00:00 URL: https://externals.io/message/38794#38801 · In reply to: #38794 I like the idea, and I think we don't need --enable-signals options. BTW I'm not sure about committing it into 5.3. It's a question to RM(s). Thanks. Dmitry. Lucas Nealan wrote: > Hi Internals, > > I am proposing the following RFC to improve signal handling in the Zend > Engine: > > http://wiki.php.net/rfc/zendsignals > > The purpose of zend internal deferred signal handling is to improve the > stability of PHP and extensions when running under any forking SAPI. > Additionally heavy users of APC or other bytecode caches under Apache 1.x > may also see a performance improvement. > > Please see follow the link above to the complete RFC for details. I look > forward to hearing feedback. > > -lucas --- ## #38836 — Stanislav Malyshev — 2008-07-07T23:23:13+00:00 URL: https://externals.io/message/38794#38836 · In reply to: #38794 Hi! > I am proposing the following RFC to improve signal handling in the Zend > Engine: > > http://wiki.php.net/rfc/zendsignals Looks good. If ti works, I don't think we need two signal models - new one would be OK. I'm not sure what happens with win32 though. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #38837 — Rasmus Lerdorf — 2008-07-07T23:49:48+00:00 URL: https://externals.io/message/38794#38837 · In reply to: #38836 Stanislav Malyshev wrote: > Hi! > > > […] > > Looks good. If ti works, I don't think we need two signal models - new > one would be OK. I'm not sure what happens with win32 though. Note that this is conceptually based on the Yahoo signal deferring mechanism. The Yahoo signal deferring code is a bit too platform-specific though, but I will walk through and see if any of the many gotchas we deal with need to be fixed in this stuff. Gopal knows this stuff as well. -Rasmus --- ## #38848 — johannes@php.net — 2008-07-08T12:00:49+00:00 URL: https://externals.io/message/38794#38848 · In reply to: #38794 Hi Lucas,  > I am proposing the following RFC to improve signal handling in the Zend > Engine: thanks for the patch, next to platform specific stuff I'm wondering whether the shutdown order is right: - /* 2. Call all possible __destruct() functions */ + /* 2. Reset max_execution_time (no longer executing php code after shutdown functions) */ + zend_try { + zend_unset_timeout(TSRMLS_C); + } zend_end_try(); + + /* 3. Call all possible __destruct() functions */ zend_try { zend_call_destructors(TSRMLS_C); } zend_end_try(); - /* 3. Flush all output buffers */ + /* 4. Flush all output buffers */ zend_try { php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1) TSRMLS_CC); } zend_end_try(); Destructors can be PHP code, as can some ob callback so I think the order should be changed. johannes > Hi Internals, > > I am proposing the following RFC to improve signal handling in the Zend > Engine: > > http://wiki.php.net/rfc/zendsignals > > The purpose of zend internal deferred signal handling is to improve the > stability of PHP and extensions when running under any forking SAPI. > Additionally heavy users of APC or other bytecode caches under Apache 1.x > may also see a performance improvement. > > Please see follow the link above to the complete RFC for details. I look > forward to hearing feedback. > > -lucas --- ## #39217 — Lukas Kahwe Smith — 2008-07-23T11:28:45+00:00 URL: https://externals.io/message/38794#39217 · In reply to: #38794 > Hi Internals, > > I am proposing the following RFC to improve signal handling in the > Zend > Engine: > > http://wiki.php.net/rfc/zendsignals > > The purpose of zend internal deferred signal handling is to improve > the > stability of PHP and extensions when running under any forking SAPI. > Additionally heavy users of APC or other bytecode caches under > Apache 1.x > may also see a performance improvement. > > Please see follow the link above to the complete RFC for details. I > look > forward to hearing feedback. Whats going on here. How does this all affect windows? Is this planned to go into 5.3? regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #39219 — Antony Dovgal — 2008-07-23T11:38:29+00:00 URL: https://externals.io/message/38794#39219 · In reply to: #38794 > Hi Internals, > > I am proposing the following RFC to improve signal handling in the Zend > Engine: > > http://wiki.php.net/rfc/zendsignals The RFC looks really nice, but we need to make a decision on it really fast, since 5_3 feature freeze is set for tomorrow. I believe this can & should go in 5_3, any objections? -- Wbr, Antony Dovgal --- ## #39225 — Antony Dovgal — 2008-07-23T12:20:29+00:00 URL: https://externals.io/message/38794#39225 > > […] > > The defines need to be there for anyone who doesn't have sigaction > available PHP_CHECK_FUNC(sigaction) in configure.in should be enough for that. -- Wbr, Antony Dovgal --- ## #39232 — Andi Gutmans — 2008-07-23T16:08:50+00:00 URL: https://externals.io/message/38794#39232 · In reply to: #39225 I want to give this a last consideration (by tomorrow). Main things are: - Checking into sigaction() support on various UNIX flavors. I am not sure that all exotic systems have it available and we want to be able to run on those (e.g. older IRIX, AIX, HP-UX versions). - Want to see what to do on Windows if anything. I don't believe we really covered this previously accept for our timeout thread so I think it is a non issue. I would prefer this patch to be in PHP 5.3 but I have a feeling we should keep the patch as-is and enable this to be configured out (don't care if it's implicit and not explicit). Andi > -----Original Message----- > From: Antony Dovgal [mailto:tony@daylessday.org] > Sent: Wednesday, July 23, 2008 5:20 AM > To: Scott MacVicar > Cc: Lucas Nealan; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Zend Signal Handling > > > > […] > > PHP_CHECK_FUNC(sigaction) in configure.in should be enough for that. > > -- > Wbr, > Antony Dovgal --- ## #39241 — Stanislav Malyshev — 2008-07-23T17:54:55+00:00 URL: https://externals.io/message/38794#39241 Hi! > Do we really need this option? > Is someone going to disable it and why? I see only reason to disable it if one has some weird system where sigaction is either absent or doesn't work as it should. Not that I know of any, but Unix variants are full of surprises. I'd keep it enabled by default, unless we are on OS that doesn't have sigaction (e.g. Windows or some extremely weird Unix) or in ZTS, of course. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39253 — Lucas Nealan — 2008-07-24T05:00:25+00:00 URL: https://externals.io/message/38794#39253 · In reply to: #39241 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. It makes sense to me to enable by default on systems that have sigaction and disable on those without. This happens curretly in the patch if it's enabled and not present. I did check some discussions from other projects where this has come up and of was found to be available on almost all systems a number of years ago. I can dig this up and add to the rfc soon. -lucas (mobile) > Hi! > > > […] > > I see only reason to disable it if one has some weird system where > sigaction is either absent or doesn't work as it should. Not that I > know of any, but Unix variants are full of surprises. > I'd keep it enabled by default, unless we are on OS that doesn't > have sigaction (e.g. Windows or some extremely weird Unix) or in > ZTS, of course. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #39255 — Pierre Joye — 2008-07-24T07:26:40+00:00 URL: https://externals.io/message/38794#39255 · In reply to: #39241 > Hi! > > > […] > > I see only reason to disable it if one has some weird system where sigaction > is either absent or doesn't work as it should. Not that I know of any, but > Unix variants are full of surprises. > I'd keep it enabled by default, unless we are on OS that doesn't have > sigaction (e.g. Windows or some extremely weird Unix) or in ZTS, of course. Windows has signal (and SigAction) support. Obviously (sigh) not using the same API but it is possible to achieve the same behaviors using the windows API. For example, there is already exception for special cases like SIGALRM, windows API also uses a timer (CreateWaitableTimer & co). Once the code is in cvs, I can give it a try to port zend_signal to windows (not before alpha1 but before alpha2 :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #39471 — Andi Gutmans — 2008-07-30T16:49:47+00:00 URL: https://externals.io/message/38794#39471 · In reply to: #39255 I would need to look into this in more detail but I am not sure sigaction is supported. In any case, these APIs on Windows tend to be more for POSIX compliance and not the "Windows way" so I am not sure there'd be a lot of value in supporting it. In any case, you should probably still take a look but keep this in mind when you're looking at MSDN :) Andi > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Thursday, July 24, 2008 12:27 AM > To: Stas Malyshev > Cc: Antony Dovgal; Scott MacVicar; Lucas Nealan; internals@lists.php.net; Andi > Gutmans > Subject: Re: [PHP-DEV] [RFC] Zend Signal Handling > > On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev wrote: > > […] sigaction > > […] any, but > > […] have > > […] course. > > Windows has signal (and SigAction) support. Obviously (sigh) not using > the same API but it is possible to achieve the same behaviors using > the windows API. For example, there is already exception for special > cases like SIGALRM, windows API also uses a timer (CreateWaitableTimer > & co). Once the code is in cvs, I can give it a try to port > zend_signal to windows (not before alpha1 but before alpha2 :) > > Cheers, > -- > Pierre > > http://blog.thepimp.net | http://www.libgd.org