Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19693
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20051022211953.psli2nyiuy8soo00@hristov.com>
Date: Sat, 22 Oct 2005 21:19:53 +0200
To: Andreas Korthaus <akorthaus@web.de>
Cc: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain;
	charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
Sender: <cpanel@iko.gotobg.net>
Subject: Re: [PHP-DEV] PHP 6.0 Wishlist    [$_PERSISTENT]
From: php@hristov.com (Andrey Hristov)

  Hi,
DIY, it's not hard. You need a semaphore (*nix) and shared memory . Semaphores
are not available on Windows but they are emulatable with ext/shmop.
More info can be found here :
http://hristov.com/andrey/projects/php_stuff/pres/writing_parallel_apps_with_PHP.pdf
sources :
http://hristov.com/andrey/projects/php_stuff/shm.php.gz

Use class Shm_Protected_Var (works on *nix only but the sources are easibly
patchable to work on windows with ext/shmop).

Cheers,
Andrey

Andreas Korthaus wrote:
> Jani Taskinen wrote:
>  >
>
>> On Sat, 22 Oct 2005, Sebastian Bergmann wrote:
>>
>>> Rasmus Lerdorf schrieb:
>>>
>>>> Include an opcode cache by default.  A lot of work has gone into
>>>> pecl/apc recently, but I am not hung up on which one goes in.
>>>
>>>
>>>
>>> In case we include APC by default, it would be nice if its apc_store() /
>>> apc_fetch() mechanism could be mapped to a new super-global, say
>>> $_PERSISTENT[].
>>
>>
>>
>>     Containing what?
>
>
>
> A super-global like $_PERSISTENT could work like $_SESSION, with a
> similar "framework", but could store data which is NOT user-specific
> like session-data.
>
> So you have a very simple methode to store any variables/objects between
> HTTP-requests. If you use something like APC as backend, you will also
> get a fast methode to store/load variables/objects, which are not
> user-specific, and perhaps expensive to create/load (e.g. from a
> webservice, DB...).
>
> The problem with "several machines serving same web pages" is exactly
> the same you have with $_SESSION today. But the session extension
> provides means to work around this using a DB or memcached as backend.
> This could be copied by something like a "Persistance Framework".
>
> But many other PHP installations will have another problem you don't see
> with $_SESSION today: concurrency. That's because you don't have a
> unique session-ID anymore, so application1 can overwrite variables from
> application2, script1.php can overwrite variables from script1.php and
> on shared hosting setups user1 can overwrite variables from user2.
> That's also a security issue.
>
> So an application-ID has been a good idea, but if you have to define it
> by yourself, chances are that two users choose the same application-ID
> and applications will break. So perhaps you also have to find some other
> values, the users cannot control, to avoid concurrency issues. Perhaps
> make a $_PERSISTENT variable only available for the script which has
> created it (by saving the path too, but if you move/rename..., and not
> very flexible anymore).
>
>
> Best regards
> Andreas
>
>
> PS: I've read the discussion on this list before ;-)
>