Re: Fwd: How to create Persistent zval?
Hi all,
Thanks for the detailed replies.
What I want to achieve is to put a router object in a persistent memory. (
see https://github.com/c9s/Pux/issues/18 )
Currently I tried to deeply copy the hash table of array property into the
persistent memory.
what I have done for the store behaviour:
1. allocate a persistent memory with pemalloc for the hash table.
2. copy the hash table from mux object's routes property to the persistent
memory, and set the persistent flag to 1.
https://github.com/c9s/Pux/blob/persistent-dispatcher/ext/php_functions.c#L113
The above link shows the hash copy function, which is a rewrite version
from apc_cache.c
3. register the hash table pointer to the EG(persistent_list) with a key.
https://github.com/c9s/Pux/blob/persistent-dispatcher/ext/php_functions.c#L373
And here is the fetch behaviour:
1. find list entry from EG(persistent_list) for specific property.
2. use zend_hash_copy to copy the persistent hash table to a non-persistent
((deeply copy, but I am not sure whether the code is correct, because it
produces some segmentation fault right now)
3. create a new router object
4. assign the newly allocated and copied hash table to the property.
5. return the new router object.
I am not sure if I done right. but there is still some segmentation faults
while storing data.
On Tue, Jan 21, 2014 at 12:23 AM, Johannes Schlüter
<[email protected]>wrote:
> Hi,
>
> On Sun, 2014-01-19 at 02:47 +0800, Lin Yo-An wrote:
> > Is there a way to keep a zval persistent in the persistent_list? Or
> > how do
> > I deeply clone an object in extension and make it persistent?
>
> What is it that *actually* want to achieve?
>
> If you want to keep the state of objects for some time then you an store
> that in persistent allocated memory buffers and extend zend_object with
> a pointer
> struct my_object { zend_object inner; custom_data *ptr };
> and then use the property hooks to "emulate" properties and accessor
> methods as your API should look like.
> Your MSHUTDOWN then has to handle the final cleanup of the data.
>
> Mind that for many deployment models of PHP request-surviving objects
> (like ASP's Application object) aren't a good architectural choice as
> PHP can live in CGI context (where there are no recurring requests), in
> FastCGI context (where there are recurring requests to multiple parallel
> processes), in IIS/apachempm/etc context (where there are multiple
> threads doing this in parallel) and multi machine context where
> recurring requests may hit different machines ... having a cheaply
> serializable format often is better.
>
> johannes
>
>
>
--
Best Regards,
Yo-An Lin
Thread (14 messages)