Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62262 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89519 invoked from network); 19 Aug 2012 16:03:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Aug 2012 16:03:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:43082] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/23-03087-86E01305 for ; Sun, 19 Aug 2012 12:03:54 -0400 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 4FE27DE13D; Sun, 19 Aug 2012 17:03:49 +0100 (BST) Date: Sun, 19 Aug 2012 17:03:49 +0100 (BST) X-X-Sender: derick@whisky.home.derickrethans.nl To: Nikita Popov cc: Stas Malyshev , Sherif Ramadan , Larry Garfield , "internals@lists.php.net" In-Reply-To: Message-ID: References: <5010138D.5050804@ajf.me> <501015B9.6050704@ajf.me> <501058B9.5050004@lsces.co.uk> <501249B6.5070507@lsces.co.uk> <50128825.4020902@lsces.co.uk> <50231FAD.40104@garfieldtech.com> <50306B5E.7050106@sugarcrm.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Re: Generators in PHP From: derick@php.net (Derick Rethans) On Sun, 19 Aug 2012, Nikita Popov wrote: > On Sun, Aug 19, 2012 at 6:28 AM, Stas Malyshev wrote: > > > >> For PHP we would need to have some similar behavior. PHP's current > >> exception model is incompatible with GeneratorExitException > >> (because PHP does not have BaseExceptions). So what I'd probably do > >> instead is monkeypatch a ZEND_RETURN opcode at the current > >> execution position and > > > > Patching opcodes is not a good idea, since opcodes could be cached, > > and the cache can be shared between different processes. > > Patching a single opcode should be okay, because it does not require > modification of the op_array. Only execute_data->opline has to be > changed (and the execute data is not shared). The exception handling > mechanism currently uses the same technique. It patches an > ZEND_HANDLE_EXCEPTION opcode into the current position. Please do not modify opcodes for running code. That is a ginormous hack and it *will* cause problems with some code. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug