Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43478 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23094 invoked from network); 26 Mar 2009 07:51:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Mar 2009 07:51:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:33430] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/67-30978-CF33BC94 for ; Thu, 26 Mar 2009 02:51:25 -0500 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 587E6414400B; Thu, 26 Mar 2009 07:54:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah2owRFSASQv; Thu, 26 Mar 2009 08:54:31 +0100 (CET) Received: from [192.168.0.151] (77-58-151-147.dclient.hispeed.ch [77.58.151.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id B702A4144009; Thu, 26 Mar 2009 08:54:30 +0100 (CET) Cc: php-dev , =?ISO-8859-1?Q?Johannes_Schl=FCter?= , Kalle Sommer Nielsen Message-ID: To: Arnaud Le Blanc In-Reply-To: <1238027452.4733.92.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 08:51:18 +0100 References: <1237469542.7120.81.camel@localhost> <9C552133-ACEE-4615-B8A3-5B16BE8660CC@pooteeweet.org> <1238027452.4733.92.camel@localhost> X-Mailer: Apple Mail (2.930.3) Subject: Re: [PHP-DEV] un-deprecating ticks ? From: mls@pooteeweet.org (Lukas Kahwe Smith) On 26.03.2009, at 01:30, Arnaud Le Blanc wrote: > On Wed, 2009-03-25 at 20:05 +0100, Lukas Kahwe Smith wrote: >> On 19.03.2009, at 14:32, Arnaud Le Blanc wrote: >> >>> Hi, >>> >>> After having seen some complaints about ticks being deprecated I'm >>> wondering if they could be un-deprecated for now. >>> >>> Ticks are used by the pcntl extension to call signal handlers when >>> signals are triggered. I added some functions as an alternative, but >>> this does not covers all use cases (and forces a code change). >>> >>> When searching bug reports about ticks, one can feel the ticks to be >>> broken (and this is why they have been deprecated). However, looking >>> in >>> depth at these bugs and viewing what caused them and how they have >>> been >>> fixed does not show really bad things about ticks. >>> >>> Actually one thing is broken (and is marked as such in the >>> documentation), tick functions do not work in ZTS, this looks >>> fixable. >>> >>> Any thoughts on removing the deprecation warning for now ? (at least >>> until a replacement is found). >>> >>> Sorry for posting this so close to the freeze. >> >> >> So what is it going to be? >> I remember everybody was happy when it was deprecated. > > The only thread I found about that is here: > http://marc.info/?l=php-internals&m=121442930703916&w=2 > >> Indeed the only open ticket is #47198, which is the doc bug. Or did >> we >> close tons of ticks bugs because it was deprecated? > > I've seen one bug marked as wont fix for this reason. I've searched > for > "ticks" and looked at the last few pages of bugs, many was really > bogus, > or documentation issues. Some was related to register_tick_function() > and are fixed. I seen nothing really bad or related to the engine. > > The ZTS issue looks fixable, this is a crash when using > register_tick_function() due to the list of functions not being > initialized > in the threads. It seems to me like at this point its your call. You are the one that has dug into this. If you feel you can fix things then I guess its your call to undeprecate ticks. As for the bogus bugs, this maybe indicate that we need to do some more work on the documentation. Could you look into this as well? Overall we should do our dearest to prevent that even stupid users can crash PHP and if something can too easily be made to still crash PHP, maybe its something we shouldnt have. regards, Lukas Kahwe Smith mls@pooteeweet.org