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
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
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
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
Leonardo Pedretti wrote:
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
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
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
Andreas Korthaus wrote:
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/19690Andrey 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
I thought 6.9 was per-process persistent
At 11:50 AM 11/24/2005, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
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.That's already on the list. See section 6.9
-Rasmus
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
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:
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/19690Andrey 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
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
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
Can't you hack this together today in PHP?
You just need runkit to register the superglobal.
--Wez.
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
$foo = $_APPLICTION['bar'];
php_application_object::read_dimension(zval *element) {
zval *baz = fetch_from_storage_mechanism(element);
return baz;
}
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
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
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:
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
Best regards,
Marcus
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:
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
Best regards,
Marcus
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.
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:
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
Best regards,
Marcus--
--
Best regards,
Marcus
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:
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:
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
Best regards,
Marcus--
--
Best regards,
Marcus
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.
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.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:
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
Best regards,
Marcus
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:
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:
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:
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
Best regards,
Marcus
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)