Re: [PHP-DEV] zend_timeout and the SIGPROF signal
I have a question in regards to page timeouts and how the initial I've noticed if a query takes longer than the default 30 seconds to execute, php returns a timeout message to the user. From what I can tell, php uses the SIGPROF signal to stop execution when the 30 seconds has expired. Also, I've found that it doesn't seem to unwind the stack I've reported it as bug #16820 and submited a patch, but no one answered ... I think it is better to use the same method as in Windows environment - set a EG(timeout) flag. regards, Wojtek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
On timeout, the engine will call zend_bailout(), which performs a
longjmp(). It does unwind the stack, but since we're dealing with C and
not C++ and there are no destructors, it's your responsibility to clean
after yourself. You can do it by properly registering your resources with
PHP's infrastructure (using the Zend Engine memory management, resource
management, etc.), which will be destroyed when the request terminates (in
this case, shortly after the longjmp()). Doing this is a good idea
(read: must) regardless of timeouts, it's the safety net that ensures that
your code will not be leaking memory and/or resources beyond the context of
a single request.
Zeev
At 16:45 20/02/2003, Jeremy Mullin wrote:
I have a question in regards to page timeouts and how the initial
request is terminated.
First, I apologize up front for my ignorance. I am not a php user,
rather a database developer who has customers using php.
I've noticed if a query takes longer than the default 30 seconds to
execute, php returns a timeout message to the user. From what I can
tell, php uses the SIGPROF signal to stop execution when the 30 seconds
has expired. Also, I've found that it doesn't seem to unwind the stack
after receiving the SIGPROF signal, instead it just seems to stop dead
in its tracks and the apache process goes back to listening for another
request.
Is my understanding somewhat correct? If so, how do I, as a library
developer, verify that some/all of my state information is returned back
to a usable state after I've been interrupted right in the middle of a
call?
I've included a pseudo-code example of my problem below, in case it
clarifies what I'm trying to say.
TIA,
J.D. Mullin
Advantage Database Server
Consider the following function:
void func( void )
{
1 - set some state flag to 1
2 - call server to do query execution
3 - set some state flag back to 0
}
The php timeout occurs during step 2.
The zend_timeout handler is called.
?? I don't know what happens next, but control never returns to my
function, so the state flag never gets set back to 0 ??
The same apache process continues to accept requests, although the libraries
that were interrupted are now in an unknown state.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
- Original Message - On timeout, the engine will call zend_bailout(), which performs a longjmp(). It does unwind the stack, but since we're dealing with C and not C++ and there are no destructors, it's your responsibility to clean after yourself. You can do it by properly registering your resources with PHP's infrastructure (using the Zend Engine memory management, resource management, etc.), which will be destroyed when the request terminates (in this case, shortly after the longjmp()). Doing this is a good idea (read: must) regardless of timeouts, it's the safety net that ensures that your code will not be leaking memory and/or resources beyond the context of a single request. Zeev It is impossible to do it in ZTS for malloc - it uses internal lock which is not a PHP resource. Long jump from signal causes that lock to be not released and we have beautiful deadlock ... Also when you use external library and it is modifying its internal structures when signal come, cleaning it is impossible (and dangerous). ZE shouldn't use zend_bailout in signal!!! regards, Wojtek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
At 17:05 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - On timeout, the engine will call zend_bailout(), which performs a longjmp(). It does unwind the stack, but since we're dealing with C and not C++ and there are no destructors, it's your responsibility to clean after yourself. You can do it by properly registering your resources with PHP's infrastructure (using the Zend Engine memory management, resource management, etc.), which will be destroyed when the request terminates (in this case, shortly after the longjmp()). Doing this is a good idea (read: must) regardless of timeouts, it's the safety net that ensures that your code will not be leaking memory and/or resources beyond the context of a single request. Zeev It is impossible to do it in ZTS for malloc - it uses internal lock which is not a PHP resource. Long jump from signal causes that lock to be not released and we have beautiful deadlock ... Then don't call malloc(). Under ZE1 there's not too much that can be done, but with ZE2, emalloc() (almost) never calls malloc() and features lock-free allocation. Also when you use external library and it is modifying its internal structures when signal come, cleaning it is impossible (and dangerous). ZE shouldn't use zend_bailout in signal!!! It absolutely should. There's no other clean way to bail out. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] zend_timeout and the SIGPROF signal
Don't call malloc? Wow, that puts some serious restrictions on what an external library can do. :) Couldn't drivers be required to implement something like SQLCancel in ODBC? A mechanism that lets the driver processing the request cancel the query nicely? -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 8:16 AM To: [EMAIL PROTECTED] Cc: Jeremy Mullin; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] zend_timeout and the SIGPROF signal At 17:05 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - On timeout, the engine will call zend_bailout(), which performs a longjmp(). It does unwind the stack, but since we're dealing with C and not C++ and there are no destructors, it's your responsibility to clean after yourself. You can do it by properly registering your resources with PHP's infrastructure (using the Zend Engine memory management, resource management, etc.), which will be destroyed when the request terminates (in this case, shortly after the longjmp()). Doing this is a good idea (read: must) regardless of timeouts, it's the safety net that ensures that your code will not be leaking memory and/or resources beyond the context of a single request. Zeev It is impossible to do it in ZTS for malloc - it uses internal lock which is not a PHP resource. Long jump from signal causes that lock to be not released and we have beautiful deadlock ... Then don't call malloc(). Under ZE1 there's not too much that can be done, but with ZE2, emalloc() (almost) never calls malloc() and features lock-free allocation. Also when you use external library and it is modifying its internal structures when signal come, cleaning it is impossible (and dangerous). ZE shouldn't use zend_bailout in signal!!! It absolutely should. There's no other clean way to bail out. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] zend_timeout and the SIGPROF signal
At 17:20 20/02/2003, Jeremy Mullin wrote: Don't call malloc? Wow, that puts some serious restrictions on what an external library can do. :) In the code that you control, obviously. Couldn't drivers be required to implement something like SQLCancel in ODBC? A mechanism that lets the driver processing the request cancel the query nicely? They have this functionality. The engine will call their request-shutdown callbacks, where they can (and should) clean after themselves. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
At 16:58 20/02/2003, [EMAIL PROTECTED] wrote: I have a question in regards to page timeouts and how the initial I've noticed if a query takes longer than the default 30 seconds to execute, php returns a timeout message to the user. From what I can tell, php uses the SIGPROF signal to stop execution when the 30 seconds has expired. Also, I've found that it doesn't seem to unwind the stack I've reported it as bug #16820 and submited a patch, but no one answered ... I think it is better to use the same method as in Windows environment - set a EG(timeout) flag. I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
- Original Message - I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause long scripts. I'd rather use EG(timeout). I'm using it now and it's working. regards, Wojtek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
At 17:38 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause long scripts. I'd rather use EG(timeout). I'm using it now and it's working. EG(timeout) is a horrible option (I wrote both, SIGPROF is by far superior). I'll try to implement a solution that won't lose the SIGPROF. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
On Thu, Feb 20, 2003 at 05:48:29PM +0200, Zeev Suraski wrote: At 17:38 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause long scripts. I'd rather use EG(timeout). I'm using it now and it's working. EG(timeout) is a horrible option (I wrote both, SIGPROF is by far superior). I'll try to implement a solution that won't lose the SIGPROF. It's possible to call zend_bailout if EG(timeout) is set in UNBLOCK_INTERRUPTIONS macro. But it doesn't solve main problem - it is not safe to just skip the stack - even PHP use locks (TSRM) and its memory allocator also use malloc/realloc/free which use locks, so it isn't safe. External libraries uses memory structures which can't be freed if paritialy modified (because SIGPROF stops modification in the middle). Trying to free them by PHP resource mechanism can cause SIGSEGV, busy loops etc. Not freeing them we loose memory ... I strongly recommend to stop using zend_bailout on timeouts (it's better to exit - it will not hang ;) regards, Wojtek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_timeout and the SIGPROF signal
On Thu, Feb 20, 2003 at 05:11:55PM +0100, Wojtek Meler wrote: On Thu, Feb 20, 2003 at 05:48:29PM +0200, Zeev Suraski wrote: At 17:38 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - I looked into the bug report, and it is true that BLOCK_INTERRUPTIONS should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause long scripts. I'd rather use EG(timeout). I'm using it now and it's working. EG(timeout) is a horrible option (I wrote both, SIGPROF is by far superior). I'll try to implement a solution that won't lose the SIGPROF. It's possible to call zend_bailout if EG(timeout) is set in UNBLOCK_INTERRUPTIONS macro. But it doesn't solve main problem - it is not safe to just skip the stack - even PHP use locks (TSRM) and its memory allocator also use malloc/realloc/free which use locks, so it isn't safe. External libraries uses memory structures which can't be freed if paritialy modified (because SIGPROF stops modification in the middle). Trying to free them by PHP resource mechanism can cause SIGSEGV, busy loops etc. Not freeing them we loose memory ... I strongly recommend to stop using zend_bailout on timeouts (it's better to exit - it will not hang ;) zeev, remember we discussed the very same thing last year (or the one before) at linuxtag in frankfurt? i also think that exit() would be the clearest thing. but it won't help in any threaded environment - so it's not an option. thing is - no matter how clever it is implemented - calling longjump from a signal handler is calling for trouble unless everybody involved beeing very careful about their critical regions. especiqal non-threadsafe libs are very likely to not even have a concept what a critical section is... re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
