Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71265 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95756 invoked from network); 19 Jan 2014 06:16:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jan 2014 06:16:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=cornelius.howl@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cornelius.howl@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.172 as permitted sender) X-PHP-List-Original-Sender: cornelius.howl@gmail.com X-Host-Fingerprint: 209.85.223.172 mail-ie0-f172.google.com Received: from [209.85.223.172] ([209.85.223.172:50647] helo=mail-ie0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 93/C5-61840-EAD6BD25 for ; Sun, 19 Jan 2014 01:16:14 -0500 Received: by mail-ie0-f172.google.com with SMTP id e14so7142282iej.31 for ; Sat, 18 Jan 2014 22:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ix7lpqIEyQAUc7VoIw27iGx8R2k9qZB5IQil9Z65McQ=; b=BIPbyvrTXxAuA+MUKgiz+/BUgOzQMETeH2kyuOUv2xyjjCUYuUhBskFL0JzmqObnvD OC8qalkS5CRi9eYlXXp4uNSUEw6q0lnEZ/KBV6ySD9Gr05BXVtUaXAAYo6GGSn31dXIF llK613dVtFWFKgpysP1vZxTrSwHLnZbw23qAnI+NHjpywTs3ENYJdjFfHtxEouHXzCA1 R2EIznKmzHOkKwcoaGzWfJhckXZ4+qRr9p6whaYummVNNZDdsegODb7PHSEcFVgIBpKm tzTw8AqrwFaegBM9ZwhGN738X8wQIym1OEGS2SfPV1WhqXjfbJ7aSpi1EbzGVXVIMhmf kEBQ== MIME-Version: 1.0 X-Received: by 10.50.42.134 with SMTP id o6mr6491989igl.18.1390112171660; Sat, 18 Jan 2014 22:16:11 -0800 (PST) Received: by 10.64.6.4 with HTTP; Sat, 18 Jan 2014 22:16:11 -0800 (PST) In-Reply-To: <52DAEC41.7020107@php.net> References: <52DAEC41.7020107@php.net> Date: Sun, 19 Jan 2014 14:16:11 +0800 Message-ID: To: Joe Watkins Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=14dae93406ad309d9e04f04cb62a Subject: Re: How to create Persistent zval? From: cornelius.howl@gmail.com (Lin Yo-An) --14dae93406ad309d9e04f04cb62a Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable Thanks again for the detailed answers and your patience. =3D] Just want to make sure the mechanism here: 1. an object can not be persistent even the object is allocated with pemalloc? I actually have tried using pemalloc then init an object few days ago, and it doesn't work. 2. an zend object can not be allocated persistently because its property HashTable or handlers is not allocated persistently by default? 3. if so, objects must be serialized to string? 4. what about array? can I make the array persistent with pemalloc allocation and without serialization? Thank you so much Yo-An Lin http://github.com/c9s On Sun, Jan 19, 2014 at 5:04 AM, Joe Watkins wrote: > On 01/18/2014 08:01 PM, Lin Yo-An wrote: > > By the way, Is this the reason of date ext always check the global > > HashTable and re-initialize the tzdata in every request? > > > > Lin Yo-An =A9=F3 2014=A6~1=A4=EB19=A4=E9=ACP= =B4=C1=A4=E9=BCg=B9D=A1G > > > >> > >> > >> Daniel Lowrey >> 'rdlowrey@php.net');>> =A9=F3 2014=A6~1=A4=EB19=A4=E9=ACP=B4=C1=A4=E9= =BCg=B9D=A1G > >> > >>>>> Hello, > >>>>> > >>>>> I am trying to store a zval object into the persistent list in zend > VM. > >>>>> (Using EG(persistent_list) and zend_rscd_list_entry) > >>>>> > >>>>> Which works fine if I store/fetch the zval in the same request > context. > >>>>> > >>>>> But it seems that zend engine cleans up the zval object after the > >>> request, > >>>>> when the next request comes, the fetched list entry points to a fre= ed > >>> zval > >>>>> address and it makes php segmentationfault. I guess zval is allocat= ed > >>> by > >>>>> emalloc, so I cant keep it cross requests? > >>> > >>>> For persistent alloc, you should use pemalloc() , which is just a > >>>> wrapper leading to libc's malloc. > >>>> If you use emalloc() , the Zend Memory Manager will free the storage > >>>> at the end of the request, thus leading to use-after-free crash if y= ou > >>>> reuse your pointer on a next request. > >>> > >>> --- Disclaimer --- > >>> I'm passing this along; Joe is having technical difficulties and aske= d > for > >>> help sending this to the list. I provide no warranties or refunds ;) > >>> --- > >>> > >>> All zvals passed into the engine must be allocated by the mm, you > cannot > >>> pemalloc anything and pass it into the engine safely. > >>> > >>> You don't want to store a persistent zval, you want to store a > persistent > >>> resource entry, which should be allocated with pemalloc(size, 1) > >>> > >>> The reason for this is when cleaning up, the engine has no means by > which > >>> to tell if a zval has been pemalloc or emalloc'd, zval_ptr_dtor works > the > >>> same for everything. > >> > >> > >> > >> Thank you so much! That is what i was guessing.. - ref cnt and pemall= oc > >> does not work for persistent zval. > >> > >> And zend engine cleans up zvals at the end of request no matter the re= f > >> cnt is? > >> > >> so zval is not persistent, then is HashTable persistent? > >> > >> It's because I need to store a zval object which has several propertie= s. > >> Is there a way to do make the object persistent? Or do i need to > serialize > >> it just like apc? > >> > >> > >> > >>> Cheers > >>> Joe > >>> > >> > >> > >> -- > >> Best Regards, > >> > >> Yo-An Lin > >> > >> > > > > A HashTable can be persistent: > > define zend_hash_init(ht, nSize, pHashFunction, pDestructor, persistent) > > HashTable *ht =3D pemalloc(sizeof(HashTable), 1); > > zend_hash_init(ht, 8, NULL, NULL, 1); > > When you write the table with zend_hash_update/add/insert the buckets > it creates are also persistently allocated. > > You don't need to serialize the data, or not necessarily anyway, a > hashtable can be copied bitwise - which in actual fact is what APC does > do. APC only serializes objects, normal arrays - HashTables are copied > bitwise, bucket by bucket. > > Of course, if the persistent table contains references to objects (as > in PHP objects in object_store or anything else emalloc'd) you will have > difficulties. > > Probably best to design the tables in such a way that they only need > ever store persistent data. > > Hope you're getting somewhere :) > > Cheers > Joe > --=20 Best Regards, Yo-An Lin --14dae93406ad309d9e04f04cb62a--