Hi Stan.
On Tue, Mar 23, 2010 at 8:47 AM, Stan Vassilev wrote:
> Thanks for your patch, but you're going to affect a whole group of users who
> do advanced logging and recovery in the shutdown phase. This is why these
> things have to be considered when they're first added.
How would they be aff
With the help of Scotts last suggestion, I made some changes. It seems
to work, but then I don't really know how to test it properly. I can
verify that A) it allows userland code the grace period of 1 second
for shutting down and B) shuts down regardless of the userland error
handler returning or
Hi!
Should monitoring of errors be needed then it might be interesting to
aggregate the server logs and filter out PHP errors. There are software
bundles who assist in this.
For those interested in the posting, it can be found here:
http://blog.naenius.com/2008/05/errorhandling-in-php-now-with-
With the help of Scotts last suggestion, I made some changes. It seems
to work, but then I don't really know how to test it properly. I can
verify that A) it allows userland code the grace period of 1 second
for shutting down and B) shuts down regardless of the userland error
handler returning or n
On Mar 22, 2010, at 11:37 AM, troels knak-nielsen wrote:
> On Mon, Mar 22, 2010 at 7:10 PM, Scott MacVicar wrote:
>>
>> Statics are bad, if its in multithreaded mode and two timeouts happen at
>> once you'll get some funny behaviour. You need to store this in the thread
>> local storage so the
On Mon, Mar 22, 2010 at 7:10 PM, Scott MacVicar wrote:
>
> Statics are bad, if its in multithreaded mode and two timeouts happen at once
> you'll get some funny behaviour. You need to store this in the thread local
> storage so the flag is per thread.
>
Thanks. My C is severely rusty; Would it
On Mar 22, 2010, at 10:55 AM, troels knak-nielsen wrote:
> On Mon, Mar 22, 2010 at 4:55 PM, troels knak-nielsen
> wrote:
>> On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke
>> wrote:
What do you mean by "no option"? Otherwise yes, that's what it does.
>>> Using sleep there is not a good pra
On Mon, Mar 22, 2010 at 4:55 PM, troels knak-nielsen wrote:
> On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke wrote:
>>> What do you mean by "no option"? Otherwise yes, that's what it does.
>> Using sleep there is not a good practice. Since the custom error
>> handler is triggered, there is no ne
Sufficool, Stanley wrote:
-Original Message-
From: Jille Timmermans [mailto:ji...@quis.cx]
Sent: Monday, March 22, 2010 9:30 AM
To: Sufficool, Stanley
Cc: 'PHP Developers Mailing List'
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on
"Maximum execution time exce
Op 22-3-2010 17:51, Sufficool, Stanley schreef:
-Original Message-
From: Jille Timmermans [mailto:ji...@quis.cx]
Sent: Monday, March 22, 2010 9:30 AM
To: Sufficool, Stanley
Cc: 'PHP Developers Mailing List'
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on
"Maximum
> -Original Message-
> From: Jille Timmermans [mailto:ji...@quis.cx]
> Sent: Monday, March 22, 2010 9:30 AM
> To: Sufficool, Stanley
> Cc: 'PHP Developers Mailing List'
> Subject: Re: [PHP-DEV] [PATCH] Raise warning first on
> "Maximum execution tim
Op 22-3-2010 17:14, Sufficool, Stanley schreef:
-Original Message-
From: Jille Timmermans [mailto:ji...@quis.cx]
Sent: Monday, March 22, 2010 8:44 AM
To: Johannes Schlüter
Cc: troels knak-nielsen; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on
"Ma
> -Original Message-
> From: Jille Timmermans [mailto:ji...@quis.cx]
> Sent: Monday, March 22, 2010 8:44 AM
> To: Johannes Schlüter
> Cc: troels knak-nielsen; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] [PATCH] Raise warning first on
> "Maximum executi
On Mon, Mar 22, 2010 at 5:04 PM, Herman Radtke wrote:
> > This patch handles timeout, not memory exhaustion.
>
> Apologies. My train of thought inexplicably switched over to memory.
> I meant to assert that your custom error handler could extend the
> length of the script to n extra seconds. Thi
> This patch handles timeout, not memory exhaustion.
Apologies. My train of thought inexplicably switched over to memory.
I meant to assert that your custom error handler could extend the
length of the script to n extra seconds. This violates that idea of
the timeout.
--
Herman Radtke
hermanrad
2010/3/22 Jille Timmermans
> Op 22-3-2010 16:14, Johannes Schlüter schreef:
>
> On Mon, 2010-03-22 at 15:51 +0100, troels knak-nielsen wrote:
>>
>>
>>> We log all errors that happens in our production environment, but as
>>> fatal errors can't be handled from within php, we end up with little
>>
On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke wrote:
> > What do you mean by "no option"? Otherwise yes, that's what it does.
> Using sleep there is not a good practice. Since the custom error
> handler is triggered, there is no need for the sleep call anyways.
>
> > I'm not sure I understand. A
On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke wrote:
>> What do you mean by "no option"? Otherwise yes, that's what it does.
> Using sleep there is not a good practice. Since the custom error
> handler is triggered, there is no need for the sleep call anyways.
So control isn't returned to the C
2010/3/22 Johannes Schlüter
> Hi,
>
> On Mon, 2010-03-22 at 16:00 +0100, Olivier B. wrote:
> > well, maybe we should provide a better behaviour for all fatal errors, no
> ?
> > A frequent one I see is the fatal error for calls like "$obj->method()",
> > when $obj is not an object.
> >
> > Isn't p
Op 22-3-2010 16:14, Johannes Schlüter schreef:
On Mon, 2010-03-22 at 15:51 +0100, troels knak-nielsen wrote:
We log all errors that happens in our production environment, but as
fatal errors can't be handled from within php, we end up with little
information to go on for further debugging. I
> What do you mean by "no option"? Otherwise yes, that's what it does.
Using sleep there is not a good practice. Since the custom error
handler is triggered, there is no need for the sleep call anyways.
> I'm not sure I understand. Are you implying that it is somehow
> possible to circumvent the
2010/3/22 Johannes Schlüter :
> A one second delay is no option there. And what actually happens is that
> the warning triggers your custom error handler. After that it sleeps
> then it dies.
What do you mean by "no option"? Otherwise yes, that's what it does.
> This also creates a "nice" way to
Hi,
On Mon, 2010-03-22 at 16:00 +0100, Olivier B. wrote:
> well, maybe we should provide a better behaviour for all fatal errors, no ?
> A frequent one I see is the fatal error for calls like "$obj->method()",
> when $obj is not an object.
>
> Isn't possible to allow catching of fatal errors, li
On Mon, 2010-03-22 at 15:51 +0100, troels knak-nielsen wrote:
> We log all errors that happens in our production environment, but as
> fatal errors can't be handled from within php, we end up with little
> information to go on for further debugging. I'm not very familiar with
> the php internals co
Hi,
well, maybe we should provide a better behaviour for all fatal errors, no ?
A frequent one I see is the fatal error for calls like "$obj->method()",
when $obj is not an object.
Isn't possible to allow catching of fatal errors, like other errors ?
Olivier
On 22/03/2010 15:51, troels knak-
Hi list.
We log all errors that happens in our production environment, but as
fatal errors can't be handled from within php, we end up with little
information to go on for further debugging. I'm not very familiar with
the php internals code, but I managed to throw in a hack that appears
to work. I
26 matches
Mail list logo
