Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43358 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59782 invoked from network); 16 Mar 2009 02:37:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2009 02:37:18 -0000 Authentication-Results: pb1.pair.com header.from=mozo@mozo.jp; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=mozo@mozo.jp; spf=permerror; sender-id=permerror Received-SPF: error (pb1.pair.com: domain mozo.jp from 209.85.198.236 cause and error) X-PHP-List-Original-Sender: mozo@mozo.jp X-Host-Fingerprint: 209.85.198.236 rv-out-0506.google.com Received: from [209.85.198.236] ([209.85.198.236:58400] helo=rv-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/DE-06903-B5BBDB94 for ; Sun, 15 Mar 2009 21:37:17 -0500 Received: by rv-out-0506.google.com with SMTP id b25so2544919rvf.23 for ; Sun, 15 Mar 2009 19:37:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.159.11 with SMTP id l11mr1893905wfo.187.1237171033271; Sun, 15 Mar 2009 19:37:13 -0700 (PDT) In-Reply-To: <49BD94B1.50005@tekrat.com> References: <49BD94B1.50005@tekrat.com> Date: Mon, 16 Mar 2009 11:37:13 +0900 Message-ID: To: shire Cc: internals Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] max_execution_time and async signal handling in apache2handler From: mozo@mozo.jp (Moriyoshi Koizumi) 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 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 =A0already covered in a proposal here: > http://wiki.php.net/rfc/zendsignals? =A0I believe the last hang-up keepin= g > 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 >