Re: max_execution_time and async signal handling in apache2handler
| From: | Moriyoshi Koizumi | Date: | Mon, 16 Mar 2009 02:37:13 +0000 |
| Subject: | Re: max_execution_time and async signal handling in apache2handler | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-43358@lists.php.net to get a copy of this message | ||
Hi,
I noticed it, but I took it as a completely different idea, something
like a performance improvement that doesn't cover the issue. It turned
out that is what I should have had a look at.
Thanks for the pointer.
Moriyoshi
On Mon, Mar 16, 2009 at 8:52 AM, shire <shire@tekrat.com> wrote:
>
> Hi Moriyoshi,
>
> Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> I got a bug report on the Japanese PHP user's list that states free()
>> aborts within the timer signal handler due to reentrance to the
>> function when max_execution_time takes effect and the signal occurs
>> within the same libc function. The reporter also states he uses
>> apache2handler, which doesn't provide block_interruptions nor
>> unblock_interruptions SAPI handlers in contrast to the apache1
>> handler.
>>
>> Whilst I doubt this happens quite frequently because PHP has its own
>> memory pool and it's far more rare that the libc's allocators get
>> called than the emalloc() and efree(), this should be addressed
>> somehow. A proposed fix is attached but note this greatly compromises
>> overall performance due to excessive system calls.
>
> Isn't this already covered in a proposal here:
> http://wiki.php.net/rfc/zendsignals? I believe the last
> hang-up keeping
> this from getting committed is in the ability to handle this properly and
> efficiently under ZTS builds, I would really like to see this get applied in
> a future PHP release though.
>
> -shire
>