Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46142 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44749 invoked from network); 21 Nov 2009 05:59:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Nov 2009 05:59:50 -0000 Authentication-Results: pb1.pair.com header.from=shire@tekrat.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=shire@tekrat.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain tekrat.com from 208.43.138.18 cause and error) X-PHP-List-Original-Sender: shire@tekrat.com X-Host-Fingerprint: 208.43.138.18 sizzo.org Linux 2.6 Received: from [208.43.138.18] ([208.43.138.18:53855] helo=sizzo.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FF/80-40936-4D1870B4 for ; Sat, 21 Nov 2009 00:59:49 -0500 Received: from shirebook.tekrat.linksys (75-101-56-2.dsl.static.sonic.net [75.101.56.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by sizzo.org (Postfix) with ESMTPSA id BF556CBE5EF; Fri, 20 Nov 2009 21:59:45 -0800 (PST) Message-ID: <4B0781CF.8070505@tekrat.com> Date: Fri, 20 Nov 2009 21:59:43 -0800 User-Agent: Postbox 1.0.2 (Macintosh/2009102216) MIME-Version: 1.0 To: PHP Internals List CC: Lucas Nealan Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Updated RFC: Zend Signal Handling From: shire@tekrat.com (shire) Lucas and I have re-visited the Zend Signal Handling RFC and have updated the patches for both the 5.3 branch and Trunk: http://wiki.php.net/rfc/zendsignals We updated the patches to deal with a bug fix that allows timeouts within the user space shutdown functions, previously multiple timeouts would not occur. To deal with this we reset the signal handlers on a timeout so that the user shutdown function can once again get a signal and behave accordingly. Per the Chicago developer meeting, it was determined that the windows timeouts are not asynchronous and thus there isn't currently any special handling required for critical sections on the windows builds. We would like to hear about any other issues/feedback with this patch, and if there's no objections get this checked in as it will assist with getting more stability for signal handling (specific example is the use of spin-locks with APC). Thanks!, -shire