# Request for Threads or SRM - Thread: https://externals.io/message/20318 - Original archive: https://news-web.php.net/php.internals/20318 - Started by Rasmus Lerdorf on 2005-11-24T20:08:15+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #20308 — D. Dante Lorenso — 2005-11-24T18:25:09+00:00 URL: https://externals.io/message/20318#20308 All, I have been trying to use PHP 5.0.5 for all my programming tasks including replacing many stand-alone Java servers. I've been successful to a degree, but I'm seriously missing Java Threads. I've written some code which uses SHM, Sockets, IPC, and PCNTL, but it's not as clean and robust as it should be. Since the jury is still deliberating over PHP6 and what it will offer, I'd like to put in my request to have a native PHP Thread object. If Threads are too much to tackle, it would be nice to have something like SRM (Script Running Machine) which could be used for CLI environment stand-alone servers. -- D. Dante Lorenso --- ## #20309 — Rasmus Lerdorf — 2005-11-24T18:39:45+00:00 URL: https://externals.io/message/20318#20309 · In reply to: #20308 D. Dante Lorenso wrote: > All, > > I have been trying to use PHP 5.0.5 for all my programming tasks > including replacing many stand-alone Java servers. I've been successful > to a degree, but I'm seriously missing Java Threads. I've written some > code which uses SHM, Sockets, IPC, and PCNTL, but it's not as clean and > robust as it should be. > > Since the jury is still deliberating over PHP6 and what it will offer, > I'd like to put in my request to have a native PHP Thread object. If > Threads are too much to tackle, it would be nice to have something like > SRM (Script Running Machine) which could be used for CLI environment > stand-alone servers. That's way outside the scope of what we have planned for PHP 6 and I can pretty much guarantee it won't happen. The SRM-like thing doesn't need to be part of PHP though. Anybody can build such a beast. -Rasmus --- ## #20310 — Leonardo Pedretti — 2005-11-24T19:02:10+00:00 URL: https://externals.io/message/20318#20310 · In reply to: #20309 > D. Dante Lorenso wrote: > > […] > > That's way outside the scope of what we have planned for PHP 6 and I can > pretty much guarantee it won't happen. The SRM-like thing doesn't need > to be part of PHP though. Anybody can build such a beast. > > -Rasmus And threads? well I must say that with php-gtk for gui client apps and php in general with all the objects engine as it is now, threads would turn it into a really powerful development framework for everything. Is there any research in the topic, or is it just sleeping waiting for the right moment to be? Leo -- Leonardo Pedretti Axon Sistemas Líder de Equipo Proyecto Basalto --- ## #20311 — Andreas Korthaus — 2005-11-24T19:19:59+00:00 URL: https://externals.io/message/20318#20311 · In reply to: #20309 Rasmus Lerdorf wrote: > > That's way outside the scope of what we have planned for PHP 6 and I can > pretty much guarantee it won't happen. The SRM-like thing doesn't need > to be part of PHP though. Anybody can build such a beast. What about something like a "persistent superglobal"? The idea is to have something like an application-wide session, not only a session per user. There could be several backends, the same way like session.save_handler setting for the session extension (e.g. files, mm, apc...). I have described that in more detail here: http://news.php.net/php.internals/19690 Andrey posted an interesting response on how to use semaphore and shm, but I was thinking about hiding the implementation and add a superglobal like $_PERSISTENT (or something like that), which can store any PHP variables between requests, like $_SESSION does, but application-wide, not separated for each user. best regards Andreas --- ## #20314 — Rasmus Lerdorf — 2005-11-24T19:50:42+00:00 URL: https://externals.io/message/20318#20314 · In reply to: #20311 Andreas Korthaus wrote: > Rasmus Lerdorf wrote: > > […] > > What about something like a "persistent superglobal"? The idea is to > have something like an application-wide session, not only a session per > user. There could be several backends, the same way like > session.save_handler setting for the session extension (e.g. files, mm, > apc...). > > I have described that in more detail here: > http://news.php.net/php.internals/19690 > > Andrey posted an interesting response on how to use semaphore and shm, > but I was thinking about hiding the implementation and add a superglobal > like $_PERSISTENT (or something like that), which can store any PHP > variables between requests, like $_SESSION does, but application-wide, > not separated for each user. That's already on the list. See section 6.9 -Rasmus --- ## #20315 — Rasmus Lerdorf — 2005-11-24T20:03:10+00:00 URL: https://externals.io/message/20318#20315 · In reply to: #20310 Leonardo Pedretti wrote: > > > […] > > And threads? well I must say that with php-gtk for gui client apps and php in > general with all the objects engine as it is now, threads would turn it into > a really powerful development framework for everything. > Is there any research in the topic, or is it just sleeping waiting for the > right moment to be? I agree that for an event-driven standalone GTK app it would make sense. It starts to make less sense in a web application where a thread is really a request. There are times when you want some asynchronous things like being able to query 100 remote urls at the same time, or you might want an asynchronous DNS lookup, but in most of these cases threads aren't actually the best way to do that. If a patch comes along that implements it in a sane manner without complicating everything we will look at it of course. But among the current core developers I don't think any of us need this so my guess is that it would take an outside effort. -Rasmus --- ## #20316 — Andi Gutmans — 2005-11-24T20:03:34+00:00 URL: https://externals.io/message/20318#20316 · In reply to: #20311 You could use a system like memcached. This kind of thing isn't really in the scope of doing it in PHP per-se. At 11:19 AM 11/24/2005, Andreas Korthaus wrote: >Rasmus Lerdorf wrote: > > […] > >What about something like a "persistent superglobal"? The idea is to >have something like an application-wide session, not only a session >per user. There could be several backends, the same way like >session.save_handler setting for the session extension (e.g. files, >mm, apc...). > >I have described that in more detail here: >http://news.php.net/php.internals/19690 > >Andrey posted an interesting response on how to use semaphore and >shm, but I was thinking about hiding the implementation and add a >superglobal like $_PERSISTENT (or something like that), which can >store any PHP variables between requests, like $_SESSION does, but >application-wide, not separated for each user. > > >best regards >Andreas --- ## #20317 — Andi Gutmans — 2005-11-24T20:05:02+00:00 URL: https://externals.io/message/20318#20317 · In reply to: #20314 I thought 6.9 was per-process persistent At 11:50 AM 11/24/2005, Rasmus Lerdorf wrote: >Andreas Korthaus wrote: > > […] > >That's already on the list. See section 6.9 > >-Rasmus --- ## #20318 — Rasmus Lerdorf — 2005-11-24T20:08:15+00:00 URL: https://externals.io/message/20318#20318 · In reply to: #20317 Andi Gutmans wrote: > I thought 6.9 was per-process persistent Yeah, they are, but they are still in the same family, I think. If you have a config.inc, for example, that populates a $config array. If you make that persistent you only have to load it once and it will be available to each request from then on. Read-only application variable in a sense. And apc already implements apc_store/apc_fetch which does this in a shared manner. -Rasmus --- ## #20391 — Sebastian Bergmann — 2005-11-25T12:44:32+00:00 URL: https://externals.io/message/20318#20391 · In reply to: #20316 Andi Gutmans schrieb: > You could use a system like memcached. This kind of thing isn't really > in the scope of doing it in PHP per-se. No, but PHP could provide a standardized frontend in the form of a super-global that can have modular backends (like we have with ext/session). One backend could then use memcached as its data store. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #20422 — Sara Golemon — 2005-11-25T18:39:27+00:00 URL: https://externals.io/message/20318#20422 · In reply to: #20391 > No, but PHP could provide a standardized frontend in the form of a > super-global that can have modular backends (like we have with > ext/session). One backend could then use memcached as its data store. > Funny, I've been thinking of just the same thing.... The PHP5 OOP hooks are just begging for that sort of implementation. $foo = $_APPLICTION['bar']; php_application_object::read_dimension(zval *element) { zval *baz = fetch_from_storage_mechanism(element); return baz; } Things like references could never be supported of course. And the userspace code would have to be intelligent enough to handle its own race conditions. (The SHM backend would cover mutexes of course, but that still doesn't solve the simpler problem of different requests handling different bundles of data) Is anyone working on something like this already? -Sara --- ## #20423 — Wez Furlong — 2005-11-25T18:54:52+00:00 URL: https://externals.io/message/20318#20423 · In reply to: #20422 Can't you hack this together today in PHP? You just need runkit to register the superglobal. --Wez. > > […] > Funny, I've been thinking of just the same thing.... The PHP5 OOP hooks are > just begging for that sort of implementation. > > $foo = $_APPLICTION['bar']; > > php_application_object::read_dimension(zval *element) { > zval *baz = fetch_from_storage_mechanism(element); > return baz; > } > > Things like references could never be supported of course. And the > userspace code would have to be intelligent enough to handle its own race > conditions. (The SHM backend would cover mutexes of course, but that still > doesn't solve the simpler problem of different requests handling different > bundles of data) > > Is anyone working on something like this already? > > -Sara --- ## #20427 — Sara Golemon — 2005-11-25T19:28:15+00:00 URL: https://externals.io/message/20318#20427 · In reply to: #20423 > > […] > > Can't you hack this together today in PHP? > You just need runkit to register the superglobal. > Sure, runkit for the suplerglobal, apc for the shm fetch/store, ArrayAccess interface for the dimension read/write. I was more curious if anyone had unified this into a common approach as opposed to a one-off unique to each implementer. -Sara --- ## #20430 — oliver.graetz@arcor.de — 2005-11-25T19:47:44+00:00 URL: https://externals.io/message/20318#20430 · In reply to: #20427 Sara Golemon schrieb: > ArrayAccess interface for the dimension read/write. Just to bring the issue up agaian: The current ArrayAccess implementation does not allow for proper simulation of arrays. This has been "broken by fixing" (tm) the method prototypes not to allow "&" anymore in interface implementations where the interface doesn't specify a "&" for the corresponding method and at the same time not changing ArrayAccess to feature a "&" for offsetGet. => You can't do $ArrayAccesImplementingObject['virtual offset'][]='test'; for offsets that are arrays. OLLi --- ## #20438 — Marcus Boerger — 2005-11-25T20:14:23+00:00 URL: https://externals.io/message/20318#20438 · In reply to: #20430 Hello Oliver, feel free to write an interface that supports return by reference and be done. Having ArrayAccess in use we had to chose one of two possibilities. First go with return by reference and second go with return by copy. We chose return by copy simply because that was the intended use anyway. That it was possible to add return by reference to its signature was an error in the first place. Actually one that we mentioned very early. But this is again ignorance and maybe not writing every tiny piece of change n some document that nobody reads anyway. And oh it is in th NEWS file. marcus Friday, November 25, 2005, 8:47:44 PM, you wrote: > Sara Golemon schrieb: > > […] > Just to bring the issue up agaian: The current ArrayAccess > implementation does not allow for proper simulation of arrays. This has > been "broken by fixing" (tm) the method prototypes not to allow "&" > anymore in interface implementations where the interface doesn't specify > a "&" for the corresponding method and at the same time not changing > ArrayAccess to feature a "&" for offsetGet. =>> You can't do > $ArrayAccesImplementingObject['virtual offset'][]='test'; > for offsets that are arrays. > OLLi Best regards, Marcus --- ## #20482 — Marian Kostadinov — 2005-11-26T03:13:03+00:00 URL: https://externals.io/message/20318#20482 · In reply to: #20438 Maybe magic implementation was a better idea for [] overrieding like for __get, __set, __isset and __unset stuff. For example __offsetGet, __offsetSet, __offsetUnset and __offsetExists (or __offsetIsset). This way people will be free using return by ref or not and also may implement only some of the methods, e.g. only __offsetGet. > Hello Oliver, > > feel free to write an interface that supports return by reference and be > done. > > Having ArrayAccess in use we had to chose one of two possibilities. First > go with return by reference and second go with return by copy. We chose > return by copy simply because that was the intended use anyway. That it was > possible to add return by reference to its signature was an error in the > first place. Actually one that we mentioned very early. But this is again > ignorance and maybe not writing every tiny piece of change n some document > that nobody reads anyway. And oh it is in th NEWS file. > > marcus > > Friday, November 25, 2005, 8:47:44 PM, you wrote: > > > […] > > > […] > > =>> You can't do > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus --- ## #20524 — Marcus Boerger — 2005-11-26T12:36:05+00:00 URL: https://externals.io/message/20318#20524 · In reply to: #20482 Hello Marian, that wouldn't buy you anything becasue even if we would allow single overrides we would have to enforce ref or non ref return. marcus Saturday, November 26, 2005, 4:13:03 AM, you wrote: > Maybe magic implementation was a better idea for [] overrieding like > for __get, __set, __isset and __unset stuff. For example __offsetGet, > __offsetSet, __offsetUnset and __offsetExists (or __offsetIsset). This > way people will be free using return by ref or not and also may > implement only some of the methods, e.g. only __offsetGet. > > > […] > -- > > Best regards, Marcus --- ## #20531 — Marian Kostadinov — 2005-11-26T12:48:15+00:00 URL: https://externals.io/message/20318#20531 · In reply to: #20524 Hm, strange. It used to work some months ago. My idea is to throw away the need of an interface for overrideing [] just like it is for ->. If you mean that C coding will be a problem...I don't know but since we were able to specify return by ref or not by ref a few months ago (before the fix), I suppose it is possible to be reimplemented. The advantage of this implementation would be quite good not just for me but for many people that benefit from the many new excelent OO (and overriding) features of PHP. > Hello Marian, > > that wouldn't buy you anything becasue even if we would allow single > overrides we would have to enforce ref or non ref return. > > marcus > > Saturday, November 26, 2005, 4:13:03 AM, you wrote: > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus --- ## #20537 — Marcus Boerger — 2005-11-26T13:01:49+00:00 URL: https://externals.io/message/20318#20537 · In reply to: #20531 Hello Marian, have a guess. Di we do this change for fun? Actually we found some nasty tricky problems. marcus Saturday, November 26, 2005, 1:48:15 PM, you wrote: > Hm, strange. It used to work some months ago. My idea is to throw away > the need of an interface for overrideing [] just like it is for ->. If > you mean that C coding will be a problem...I don't know but since we > were able to specify return by ref or not by ref a few months ago > (before the fix), I suppose it is possible to be reimplemented. The > advantage of this implementation would be quite good not just for me > but for many people that benefit from the many new excelent OO (and > overriding) features of PHP. > > > […] --- ## #20552 — ondrej@kmit.sk — 2005-11-26T14:39:40+00:00 URL: https://externals.io/message/20318#20552 · In reply to: #20422 Sara Golemon wrote: > Is anyone working on something like this already? I don't known what you exactly meaning, but I'm playing with 'The Spread Toolkit' [1] a their PECL interface [2]. I was started research phase of project only. The goal of my work is to create sessions handling across multiple servers. I'm looking for something like "Zend Platform's Session Clustering Module" and Spread toolkit looks good for this. [1] http://www.spread.org/ [2] http://pecl.php.net/package/spread -- Ondrej Ivanic (ondrej@kmit.sk) --- ## #20553 — Marian Kostadinov — 2005-11-26T14:53:08+00:00 URL: https://externals.io/message/20318#20553 · In reply to: #20537 Yes, I remember. It was not for fun. I agree that this is a low priority feature just now while many important issues are to be solved. > Hello Marian, > > have a guess. Di we do this change for fun? Actually we found some nasty > tricky problems. > > marcus > > Saturday, November 26, 2005, 1:48:15 PM, you wrote: > > > […] > > > > > […]