Fixed crash in fastcgi due startup order...
SIGG() were being used before tsrm_startup().
2011/6/4 Felipe Pena
> Fixed invalid sigaction() call passing NSIG as signal number.
>
> - for (signo = 1; signo <= NSIG; ++signo) {
> + for (signo = 1; signo < NSIG; ++signo) {
>
> Detected by Valgrind:
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo <= NSIG; ++signo) {
+ for (signo = 1; signo < NSIG; ++signo) {
Detected by Valgrind:
==4577== Warning: bad signal number 65 in sigaction()
2011/6/3 Ilia Alshanetsky
> The crash is now fixed as well.
>
> On F
The crash is now fixed as well.
On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena wrote:
> 2011/6/2 Felipe Pena
>
>> Hi,
>>
>> 2011/6/2 Michael Maclean
>>
>>> On 02/06/11 18:20, Gustavo Lopes wrote:
>>>
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
escreveu:
Killing TSRML
2011/6/2 Felipe Pena
> Hi,
>
> 2011/6/2 Michael Maclean
>
>> On 02/06/11 18:20, Gustavo Lopes wrote:
>>
>>> Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
>>> escreveu:
>>>
>>> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the rec
Hi,
2011/6/2 Michael Maclean
> On 02/06/11 18:20, Gustavo Lopes wrote:
>
>> Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
>> escreveu:
>>
>> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
>>> at a time please ;-) And for the record I am all for killing
>>> TSRMLS_
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opp
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opposed to simply not use it?
You will be
On Thu, Jun 2, 2011 at 7:10 PM, Ilia Alshanetsky wrote:
> Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
> at a time please ;-)
I mean in this patch only. This patch adds a couple, so it can be done
at the same time (afair these functions are not used heavily outside
the en
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye wrote:
> hi Ilia,
>
> I would suggest to kill the TSRMLS_FETCH while being at it. They are
> horribly slow a
On 05/31/2011 03:30 PM, Ilia Alshanetsky wrote:
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite h
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
horribly slow and a couple of them can be replaced by the
TSRMLS_DC/CC, if I'm not mistaken.
For the windows side, I do not have the time to do the equivalent, so
if you commit the patch to trunk first so I can fix the
On 05/31/2011 03:35 PM, Stas Malyshev wrote:
> Hi!
>
>> The patch is solid (have been using it in production for quite some
>> time) and improvement is quite helpful, especially when APC is being
>> used. Are there any reasons not to apply this to 5.4?
>
> I don't know of any. Are there any issue
Hi!
I do not believe so.
Then I guess if nobody has any objections we can do it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I do not believe so.
On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev wrote:
> Hi!
>
>> The patch is solid (have been using it in production for quite some
>> time) and improvement is quite helpful, especially when APC is being
>> used. Are there any reasons not to apply this to 5.4?
>
> I don't kn
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
I don't know of any. Are there any issues with this change (BC, etc.)?
--
Stanislav Malyshev, Softw
How shall we continue with this patch?
Arnaud, I need an updated HEAD patch to match the changes made in 5.3.
There's valid concern about performance in ZTS, which seems hard to address
without the __thread changes. It seems you are working on to get this into
6.0.
Dmitry, Lukas, Arnaud and othe
On Thursday 14 August 2008 02:59:48 Arnaud Le Blanc wrote:
> Hi,
>
> I made some changes to the patch:
>
> http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808141122.patch
>
> - Apache effectively seems to resets the signals after MINIT, so original
> handlers are now saved in RINIT in the first
Hi,
On Thursday 14 August 2008 04:19:38 Rasmus Lerdorf wrote:
> Arnaud Le Blanc wrote:
> > - Apache effectively seems to resets the signals after MINIT, so original
> > handlers are now saved in RINIT in the first request of the process.
>
> Did you verify this behaviour with Apache2 as well? I'v
Arnaud Le Blanc wrote:
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
Did you verify this behaviour with Apache2 as well? I've only checked
Apache1.
-Rasmus
--
PHP Internals - PHP Runtime Devel
Hi,
I made some changes to the patch:
http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808141122.patch
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
- Removed some unneeded blocks/unblocks.
- Cha
Hi,
On Wednesday 13 August 2008 10:09:43 Dmitry Stogov wrote:
> Hi Lucas,
>
> I took a look into patch and I still don't like it.
> I may miss some things and make mistakes so correct me if I'm wrong.
>
> 1) It makes some slowdown for all SAPIs except Apache1, because it adds
> additional block/u
now I see the main reason of the patch, but while APC is not a part of
PHP yet, it might be better, easer and safer to solve its issue in APC
itself (this is just a though, not a recommendation).
Anyway we need to make this patch better if we commit it, and I would
ask other community members
On 8/13/08 2:10 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I wasn't serious about removing them.
>
> Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
> It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
> it's not its primary purpose. If APC don't do it I
On 8/13/08 1:09 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I took a look into patch and I still don't like it.
> I may miss some things and make mistakes so correct me if I'm wrong.
> 1) It makes some slowdown for all SAPIs except Apache1, because it adds
> additional block/unblock code (mai
I wasn't serious about removing them.
Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
it's not its primary purpose. If APC don't do it I don't see how this
block/unblock code may protect SHM. It definitely m
Dmitry Stogov wrote:
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional blo
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainl
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
This is the pa
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
2) It makes ~10 additional syscalls
On 8/11/08 8:52 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I'll try to review it on Tuesday/Wednesday.
> Thanks. Dmitry.
I've just updated the patches. Only some very minor changes as discussed
before and they should cleanly apply against current cvs.
-lucas
--
PHP Internals - PHP Runti
I'll try to review it on Tuesday/Wednesday.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
On 09.08.2008, at 17:42, Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review
the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have b
On 09.08.2008, at 17:42, Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review
the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded e
Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded environments, and fixes many pr
Hi,
As Lucas said the patch seems ready now, could someone please review the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded environments, and fixes many problems
on non-windows p
On 8/5/08 3:45 AM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> In the case of pcntl_signal(), if it registers a handler for a signal, the
> signal will be delivered to zend_signal_handler_defer(), which will call
> zend_signal_handler() if not in critical section, which will call the actual
> h
On Tuesday 05 August 2008 12:28:19 Lucas Nealan wrote:
> On 8/4/08 11:51 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> > global_sigmask is initialized using sigfillset(), so it contains _all_
> > signals (except SIGSEGV, etc because non-blockable or not safe to block)
> > and there is no need
On 8/4/08 11:51 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> global_sigmask is initialized using sigfillset(), so it contains _all_ signals
> (except SIGSEGV, etc because non-blockable or not safe to block) and there is
> no need to add signals to global_sigmask it in zend_signal() /
> zen
On Tuesday 05 August 2008 08:51:33 Arnaud Le Blanc wrote:
> Votre message:
> > Greetings!
> >
> > On 8/3/08 9:37 PM, "Arnaud LB" <[EMAIL PROTECTED]> wrote:
> > > If sigaction is not available Zend Signal Handling will not be
> > > enabled, so it will not be enabled on Windows (I assume sigaction is
Votre message:
> Greetings!
>
> On 8/3/08 9:37 PM, "Arnaud LB" <[EMAIL PROTECTED]> wrote:
> > If sigaction is not available Zend Signal Handling will not be
> > enabled, so it will not be enabled on Windows (I assume sigaction is
> > not available on Windows, it is ?).
> > For pthreads and sigproc
Greetings!
On 8/3/08 9:37 PM, "Arnaud LB" <[EMAIL PROTECTED]> wrote:
> If sigaction is not available Zend Signal Handling will not be
> enabled, so it will not be enabled on Windows (I assume sigaction is
> not available on Windows, it is ?).
> For pthreads and sigprocmask, tsrm_sigmask() can be i
On Sun, Aug 3, 2008 at 9:34 AM, Lucas Nealan <[EMAIL PROTECTED]> wrote:
> Reviewed to my ability and will soon be posting the updated patch for 5_3
> and 6 as well as wiki changes.
>
> On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
>> The ZTS-enabled version of your patch can be fo
On Mon, Aug 4, 2008 at 1:33 AM, Steph Fox <[EMAIL PROTECTED]> wrote:
>> I do not know either, only pointed that we release non ZTS windows
>> build as well, just in case :)
>
> So user confusion is not an issue here?
It is off topic yes. The only point discussed here is whether the
signal handlin
I do not know either, only pointed that we release non ZTS windows
build as well, just in case :)
So user confusion is not an issue here?
Just asking, on account of the amount of user confusion over NTS/ZTS in
php-gtk2 history since that became an option...
- Steph
--
PHP Internals - PH
Hi Lucas,
On Sun, Aug 3, 2008 at 11:06 PM, Lucas Nealan <[EMAIL PROTECTED]> wrote:
> On 8/3/08 3:00 AM, "Pierre Joye" <[EMAIL PROTECTED]> wrote:
>
>> We also provide binaries for non ZTS mode, so if the patch is not
>> ready for Windows, it should disable this feature on Windows.
>
> I was presumi
On 8/3/08 3:00 AM, "Pierre Joye" <[EMAIL PROTECTED]> wrote:
> We also provide binaries for non ZTS mode, so if the patch is not
> ready for Windows, it should disable this feature on Windows.
I was presuming that non-zts, non-cygwin windows will not satisfy the
sigaction requirement, thus we woul
hi!
On Sun, Aug 3, 2008 at 9:34 AM, Lucas Nealan <[EMAIL PROTECTED]> wrote:
> Reviewed to my ability and will soon be posting the updated patch for 5_3
> and 6 as well as wiki changes.
>
> On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
>> The ZTS-enabled version of your patch can
Reviewed to my ability and will soon be posting the updated patch for 5_3
and 6 as well as wiki changes.
On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> The ZTS-enabled version of your patch can be found at [1] :)
> Changes:
> Zend Signal Handling is now enabled in ZTS builds.
S
On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> Hi,
> The ZTS-enabled version of your patch can be found at [1] :)
Thanks Arnaud. I've gone ahead and made the HEAD patch already, wasn't as
bad as I thought it might be. I'll review this hopefully by tomorrow and
then pull into my
On Friday 01 August 2008 13:27:44 Lucas Nealan wrote:
> Hi!
>
> On 7/31/08 11:07 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
>
> > I worked a bit on the ZTS version, this actually fixes many problems with
ZTS
> > on non-windows plateforms :)
> [...snip...]
> > I will send a modified version
Hi!
On 7/31/08 11:07 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> I worked a bit on the ZTS version, this actually fixes many problems with ZTS
> on non-windows plateforms :)
[...snip...]
> I will send a modified version of your patch tomorrow.
Sounds great, can't wait to see what you've g
Hi,
On Friday 01 August 2008 05:39:27 Lucas Nealan wrote:
> I was initially planning to implement ZTS, however the more I learned the
> harder it became. The first issue being that not every scope implementing
> the blocking macros has implemented or fetched TSRMLS data. Many places in
> zend_allo
On 7/30/08 11:54 AM, "Stanisla Malyshev" <[EMAIL PROTECTED]> wrote:
> I have a couple of questions about the patch:
> 1. Why allocate fixed-size buffer via individual malloc's on each
> activate and free it on each deactivate? Won't it be better to just
> allocate it once and use it?
I'll take a l
> On 7/30/08 6:11 AM, "Lukas Kahwe Smith" <[EMAIL PROTECTED]> wrote:
> Not so happy that it was not possible to get this committed over the
> weekend. Johannes did a quick review and it seems like it has enough
> support from people and is low risk enough to get committed now. Lets
> hope no extens
I would suggest not to apply it in the rush.
We will able to apply it after Alpha1 release.
It is not a major change for end users.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
>
> On 30.07.2008, at 21:05, Arnaud Le Blanc wrote:
>
>> On Wednesday 30 July 2008 20:46:13 Jani Taskinen wrote:
>>> Arnau
On Wednesday 30 July 2008 20:46:13 Jani Taskinen wrote:
> Arnaud Le Blanc kirjoitti:
> > Hi,
> >
> > On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
> >> I see several issues with the patch
> >>
> >> 1) It assumes that web server (and webserver extensions) won't setup any
> >> signal handl
On 30.07.2008, at 21:05, Arnaud Le Blanc wrote:
On Wednesday 30 July 2008 20:46:13 Jani Taskinen wrote:
Arnaud Le Blanc kirjoitti:
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't
Hi!
I have a couple of questions about the patch:
1. Why allocate fixed-size buffer via individual malloc's on each
activate and free it on each deactivate? Won't it be better to just
allocate it once and use it?
2. Why define own SIG_UNEXPECTED - we already have UNEXPECTED macro in
the engine
Arnaud Le Blanc kirjoitti:
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
2) It is incompatible with ext/p
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
> I see several issues with the patch
>
> 1) It assumes that web server (and webserver extensions) won't setup any
> signal handlers after PHP startup. This assumption may be wrong.
>
> 2) It is incompatible with ext/pcntl
If zend_sign
Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
It may be. But there is really no way around that. That's why we
talked about having an optional
p.net; Andi
> Gutmans
> Subject: Re: [PHP-DEV] [RFC] Zend Signal Handling
>
> On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev <[EMAIL PROTECTED]>
wrote:
> > Hi!
> >
> >> Do we really need this option?
> >> Is someone going to disable it and why?
&
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
2) It is incompatible with ext/pcntl
3) It breaks 3 tests (in debug mode)
tests/classes/destructor_visibility_001.phpt
te
I'll do quick review in an hour and then I'll probably commit it.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
>
> On 30.07.2008, at 01:58, Lucas Nealan wrote:
>
>> I've updated the patch for Zend Signal Handling, the latest version is
>> available on the wiki rfc page:
>>
>> http://wiki.php.net/rf
On 30.07.2008, at 01:58, Lucas Nealan wrote:
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
http://wiki.php.net/rfc/zendsignals
The update solves the reentrance issue with using the a zend linked
list in
the default signal handler. I'v
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
http://wiki.php.net/rfc/zendsignals
The update solves the reentrance issue with using the a zend linked list in
the default signal handler. I've also added a debug only check, at least for
now,
> 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 oversig
On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> 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 t
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 oversight
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 defau
mplicit and not explicit).
Andi
> -Original Message-
> From: Antony Dovgal [mailto:[EMAIL PROTECTED]
> 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
>
&
On 23.07.2008 16:08, Scott MacVicar wrote:
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
--
PH
Antony Dovgal wrote:
On 23.07.2008 15:42, Scott MacVicar wrote:
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?
Enable it
On 23.07.2008 15:42, Scott MacVicar wrote:
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?
Enable it by default and change
Antony Dovgal wrote:
On 06.07.2008 22:56, 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 RFC looks really nice, but we need to make a decision on it really
fast, since 5_3 feature free
On 06.07.2008 22:56, 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 RFC looks really nice, but we need to make a decision on it really fast,
since 5_3 feature freeze is set for tomorrow
On 06.07.2008, at 20:56, 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 ru
Hi Johannes,
> thanks for the patch, next to platform specific stuff I'm wondering
> whether the shutdown order is right:
> [..snip..]
> Destructors can be PHP code, as can some ob callback so I think the order
> should be changed.
Yes, great catch, the order is incorrect. We use a different orde
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
Hi Stas,
> 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.
This has not been tested on windows but it `should` be unaffacted. If built
with ZEND_MAINTAINER_ZTS or if sigaction() is not detected then ZEND_SIGNAL
Stanislav Malyshev wrote:
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.
Note that
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 A
Hi Dmitry,
> I like the idea, and I think we don't need --enable-signals options.
I would like to have this enabled by default and this would be very easy to
change. We¹ve been running in production for a few months and we use the
option to make it easier to disable at build time for testing. Ide
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
83 matches
Mail list logo