Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39537 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49624 invoked from network); 1 Aug 2008 11:48:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Aug 2008 11:48:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=stefan.esser@sektioneins.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=stefan.esser@sektioneins.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain sektioneins.de from 85.214.103.31 cause and error) X-PHP-List-Original-Sender: stefan.esser@sektioneins.de X-Host-Fingerprint: 85.214.103.31 h1332034.stratoserver.net Linux 2.6 Received: from [85.214.103.31] ([85.214.103.31:11181] helo=h1332034.stratoserver.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0F/02-39007-0F7F2984 for ; Fri, 01 Aug 2008 07:48:03 -0400 Received: from Very-Black-Mac.lan (port-87-193-248-162.static.qsc.de [87.193.248.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by h1332034.stratoserver.net (Postfix) with ESMTP id 43D37A245AA; Fri, 1 Aug 2008 13:43:40 +0200 (CEST) Message-ID: <4892F813.6050402@sektioneins.de> Date: Fri, 01 Aug 2008 13:48:35 +0200 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Dmitry Stogov CC: Marcus Boerger , PHP Internals List References: <4890CC7A.6060303@sektioneins.de> <416879664.20080801004706@marcus-boerger.de> <4892F46A.1060008@zend.com> In-Reply-To: <4892F46A.1060008@zend.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Switch Table Extension for PHP From: stefan.esser@sektioneins.de (Stefan Esser) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Dmitry, while I also believe that the extension should not be included in the core at the moment I strongly believe that it will be compatible with every well behaving opcode cache. Because it modifies op_array during execution... a) the opcode cache is not affected at all because it always provides a copy of the cached op_array to execute() or b) the modification will be performed on the cached opcodes in memory which means the opcode cache either stores (and therefore shares) the manipulated opcodes (with other processes) or not. Either way any process loading the opcodes that were manipulated by another process should recognise the loaded op_array as not yet optimized. Therefore the optimization will be repeated in the other process again => No problem at all. Therefore only on edge cases, where 2 processes share the same memory addresses for the switchtables a malfunction due to an opcode cache can happen. (I will improve that by a canary value that is different for each process and that I will store in the extented_value of the JMPZ opcode that is following the CASE) Attention: switchtable is not threadsafe at the moment Stefan Esser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiS+BMACgkQSuF5XhWr2nhGxQCgn1EPNaZS3ndUZG4DKTQ2+njk 7lwAnjiTWCoInAbR1jTY+4B6vdEm8NLd =+8w7 -----END PGP SIGNATURE-----