[RFC] Zend Signal Handling View as Markdown

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

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

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

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

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

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

Do we really need this option?
Is someone going to disable it and why?

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

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!

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

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.

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