Re: PATCH: zend_mm_heap_overflow()
| From: | shire | Date: | Mon, 19 Jan 2009 23:06:58 +0000 |
| Subject: | Re: PATCH: zend_mm_heap_overflow() | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-42717@lists.php.net to get a copy of this message | ||
Stanislav Malyshev wrote:
Hi!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! -shireYes, 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.