Morning,

> I think it's a bug in APC. Each extension has its own slot, by
> allocated slot number, and should never touch other slots (unless it
> has some protocol to talk to the extension which owns other slot). So
> touching slot that is not owned by the code is a bug like touching
> unallocated memory.
Yes it was a bug in APC. But the problem is that I doubt it is clearly
documented how to get access to the "reserved resourced".
Actually I believe Suhosin was the first open source solution that used
these resources and the only closed source software that did it (and dit
it long before Suhosin) are Zend tools.

> Well, we can't have pointers to disk in memory :), so disk is another
> problem. As for shared memory, I don't see how one can support
> arbitrary length and structure data without using pointers in one way
> or another, so once you share that you'd have to use shared memory
> pointers anyway. Maybe I misunderstand something in what do you mean -
> could you tell some more on what would be the improvement you are
> thinking of?
Well the problem I want to be solving is the following
1) Extension generated extra data that is linked to the op_array (f.e.
information like: was generated by eval()'d code, does use variable XYZ,
uses session functionality, ....)
2) Naive way is to reserve a slot and simply put a pointer in there
3) Naive way works when there is no opcode cache, because then the extra
data has to be regenerated everytime anyway (SLOW!)
4) Naive way works when the opcode cache does only work on a per
process/thread basis, because then the pointer stays valid
5) Naive way FAILS when opcode cache stores data on disk and loads it
back (pointer wrong, or process never generated the extra data)
6) Naive way FAILS when opcode cache shares data between processes
(pointer wrong, ...)

Now the idea was to create a solution for this problem that is
compatible with all opcode cachers that follow some rules.

Correct me if I am wrong, but I believed that op_arrays in shared memory
cannot be used directly and usually have to be copied into the own
address space to work on...
If this is true then maybe the simplest idea would be to have some kind
of suspend and resume functionality for op_arrays.
When you put the op_array into the shared memory you call a suspend
hook() extensions can register and when you read it from shared memory
you call the resume() hook.

This would be the simplest way, because then the extension could maybe
clear its pointer in the extra slot so that it is NULL for the other
process and then it knows inside the other process that it has to
regenerate it for the other process. Or it simply regenerates the
information from within the resume_hook().

I think this idea is pretty simple to implement.

But my original idea was a little bit more complicated. I wanted that
the suspend hook creates a binary data package (by extension) and that
when the opcode cacher caches the binary data package it copies the data
of the suspend hook into shared memory/writes it onto disk. On the other
hand the resume hook will decode the extra data...

To make it simple for the opcode cachers PHP could internally handle the
whole combine data of extensions and split up data by extension stuff.

So for opcode cachers they simply have to:
1) zend_suspend_op_array(op_array, *buffer, *size);
2) Store the extra data in buffer of size bytes together with the op_array
3) zend_resume_op_array(op_array, buffer, size);

I know that there are some op_array() hooks for zend_extensions but I
believe right now there is no way to hook "I just came from some kind of
shared memory (memory/disk/network)" please fix me up so that I still
work in your process....

Stefan Esser

-- 
Stefan Esser                 SektionEins GmbH
Tel. +49 175 6782326         Ober Buschweg 9a
                             50999 Köln
[EMAIL PROTECTED]  www.sektioneins.de

SektionEins GmbH, Standort Köln
Firmensitz: Ober Buschweg 9a, 50999 Köln
Registergericht: Amtsgericht Köln, HRB 59920
Geschäftsführer: Johann-Peter Hartmann

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to