Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66623 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59532 invoked from network); 14 Mar 2013 17:47:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Mar 2013 17:47:34 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.25 out1-smtp.messagingengine.com Received: from [66.111.4.25] ([66.111.4.25:59165] helo=out1-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/32-48242-33D02415 for ; Thu, 14 Mar 2013 12:47:32 -0500 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F061720B88 for ; Thu, 14 Mar 2013 13:47:28 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 14 Mar 2013 13:47:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gUUpYlw+WJevEiDQlT76Ma n+PEY=; b=Gi1kyw4tq53tIUe6833vQ6jZX3ZwnPv/M3x1ZO4NodC1IVZsjj3/MS 5fkQ8EtKCv9n92sJu/lcXirZJLKeJ/a+LthnCkUEW1Y94GhDNjxQbN+Du39cu9DY F1a24LCIu6AEWId5QlHUoTrcM0QnCCh+AaVZ2IX3BoyVcrqLpRecY= X-Sasl-enc: 3kj/zajRldt7MyBEMsCQDFQq0/NuFHbJy4EjRO6O0iBB 1363283248 Received: from Palantirs-MacBook-Pro.local (unknown [63.250.249.138]) by mail.messagingengine.com (Postfix) with ESMTPA id B1095C80E8B for ; Thu, 14 Mar 2013 13:47:28 -0400 (EDT) Message-ID: <51420D30.8060005@garfieldtech.com> Date: Thu, 14 Mar 2013 12:47:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: internals@lists.php.net References: <51420567.8000309@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] feature request : easy shared memory From: larry@garfieldtech.com (Larry Garfield) On 3/14/13 12:28 PM, Bob Weinand wrote: > Am 14.3.2013 um 18:14 schrieb Rasmus Lerdorf : > >> On 03/14/2013 09:13 AM, Bob Weinand wrote: >>> And there is no possibility to store the zval as raw binary data like in memory (deep copy?) >>> So that you only have to copy from ram? And replace the pointers to the place in the string? >>> This must be possible I think. And should be faster. >>> >>> shmop has to be opened on every request and only supports strings. >>> APC, memcache,... can only save under serialized form which is slow. >> >> APC doesn't serialize most types. Only actual objects need to be >> serialized because it is the easiest way to fully save and restore >> objects. eg. calling their __sleep()/__wakeup() magic methods, etc. >> Arrays are not serialized. >> >> -Rasmus > > Thanks, ..., okay, didn't know that. > > But even now I am in favor of a new keyword as it will be easier to have a reference to the > shared memory (written in and reread from memory when modified) than every time refetching it > when the shared memory block may have changed in an other program (what could really reduce > race-conditions implicitly as as a developer you may forget to refetch the variable from shared > memory). Yes, refetching always is already possible with an userland getter/setter, but I don't think > it's best practice to do so in PHP... > > Bob Weinand Sharing active memory between processes goes against the "shared nothing" design of PHP. The lack of the feature you're describing is itself a feature. :-) If you had real shared memory, then you're now writing a multi-threaded app. Even if you aren't using threads per se it's the same level of potential for spooky action at a distance. If your problem space really requires that (and there certainly are those that do), Java or NodeJs will suit you better because those are built specifically for a persistent-server model, rather than PHP's shared-nothing design. However, in practice most PHP/web applications don't need that, because HTTP is a stateless request/response system. Shared-nothing more closely models what the actual environment is doing, and can still be very performant as long as you don't do anything naive. If you're doing something stateful like Web Sockets, then you can run PHP as a cli application that is its own persistent server rather than as an Apache add-on. For that, look at Ratchet: http://socketo.me/ --Larry Garfield