Re: max_execution_time and async signal handling in apache2handler

From: 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 >

« previous php.internals (#43358) next »