Re: PHP 6.0 Wishlist [$_PERSISTENT]

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 ;-) >