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 <johannes@schlueters.de>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