Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42717 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95131 invoked from network); 19 Jan 2009 23:07:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jan 2009 23:07:03 -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 69.63.177.213 cause and error) X-PHP-List-Original-Sender: shire@tekrat.com X-Host-Fingerprint: 69.63.177.213 sizzo.org Linux 2.6 Received: from [69.63.177.213] ([69.63.177.213:38826] helo=sizzo.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/65-04172-69705794 for ; Mon, 19 Jan 2009 18:07:03 -0500 Received: from shirebook.local (c-76-102-73-78.hsd1.ca.comcast.net [76.102.73.78]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by sizzo.org (Postfix) with ESMTPSA id 89CC84FA6B6; Mon, 19 Jan 2009 15:06:59 -0800 (PST) Message-ID: <49750792.6090703@tekrat.com> Date: Mon, 19 Jan 2009 15:06:58 -0800 User-Agent: Postbox 1.0b3 (Macintosh/2009011516) MIME-Version: 1.0 To: Stanislav Malyshev CC: PHP Internals List References: <4973DB36.3010703@tekrat.com> <4974C4DE.3040203@zend.com> <4974EB88.9020804@tekrat.com> <4974F3F7.2000806@zend.com> In-Reply-To: <4974F3F7.2000806@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PATCH: zend_mm_heap_overflow() From: shire@tekrat.com (shire) Stanislav Malyshev wrote: > Hi! > >> Yes, I like this idea better as it's more flexible but I wasn't sure >> if we wanted that much visibility into the global variables of the >> allocator. I suppose though, as with other things of this nature, if >> you're mucking with this data then you should be doing so at your own >> risk etc. ;-) > > Well, messing up AG is not worse than messing up EG or CG - you'll end > up crashing pretty soon anyway :) Only problem might be that it may > introduce binary dependencies that will limit what we can do in memory > manager between versions, so we need to consider this carefully. Yeah, definitely makes sense. I'm also going on the assumption that this might be useful at some point later on, rather than my single use case. Of course if it isn't then we don't have to worry about binary compatibility either lol. I hadn't considered creating a hybrid approach to this, perhaps that might be a good alternative. Rather than exposing the entire structure or creating one-off access functions (which has it's own BC issues), perhaps we should expose a new structure that is just a portion of the existing heap structure so we can expose only those items that we're willing to support. This won't fix everything, but at least it might mitigate problems associated with opening up the entire existing heap structure and allow some flexibility with BC if it does change. If it's interesting to everyone and saves you some time I can work up a patch so we can see what that might look like too. Thanks! -shire