Hello PHP folks,
I've seen this discussed previously, and would like to add a few
arguments for the multi-threading side vs. async processing,
which I've seen mentioned as a viable alternative:
1. Imagine that from time to time, some background processing takes 1
On 04/01/2010 07:32 AM, speedy wrote:
1. Imagine that from time to time, some background processing takes 1
second of CPU time - w/o multithreading, all your async operations,
like accepting a connection to a socket, aio or others are basically
stalled. So, async is a
Hello Rasmus,
Thursday, April 1, 2010, 5:21:55 PM, you wrote:
On 04/01/2010 07:32 AM, speedy wrote:
1. Imagine that from time to time, some background processing takes 1
second of CPU time - w/o multithreading, all your async operations,
like accepting a connection to a
On 04/01/2010 09:03 AM, speedy wrote:
Also, keep in mind that the web is slowly shifting towards real-time
communication
/ streaming with emergence of Comet, HTML5 Web Sockets etc. There are already
many web
server implementations specialising in that, and PHP is _not_ their language
of
Hello Rasmus,
Thursday, April 1, 2010, 6:16:21 PM, you wrote:
In any sort of Web architecture native threading in PHP just doesn't
make any sense.
Imagine a real-time websockets/HTTP based server processing architecture with
quick event passing from one connection to another with possibility
On Thu, Apr 1, 2010 at 12:57 PM, speedy speedy.s...@gmail.com wrote:
Now imagine a whole web server written in PHP (ie. nanoserv), say, using
libevent as the network backend, running the above described real-time web
implementation. Alternatively, you could perhaps even wire it into
Now imagine a whole web server written in PHP (ie. nanoserv), say, using
libevent as the network backend, running the above described real-time web
implementation. Alternatively, you could perhaps even wire it into worker/event
model of apache/other servers instead of rolling your own. It sounds
Hi!
processing, but then the state syncing of the forked background
processing
results with the main thread requires a whole new protocol / switching to
interprocess communication, which makes such developments unnecessarily
hard. Threads exist for a _reason_ not
On 01.04.2010 22:38, Stanislav Malyshev wrote:
If you do, how you control access to them? Hello locks and the whole can
of worms! Most people that think they can program in threads actually
are just pushing their luck until some complex interaction leaves their
app malfunctioning in a
are we talking about having a thread safe PHP or parallel-like
features available in user land?
The sooner needs some love to be actually true, while most of the
issues come from external libs. The later makes little or no sense.
On Thu, Apr 1, 2010 at 8:52 PM, Antony Dovgal t...@daylessday.org
Hey Internals,
In our work converting the Zend Framework library to namespaces, we came
across some inconsistencies in constructor namings.
Clearly, with namespace support making class names shorter, we come back
full circle where some class names collide with reserved words, thus we
are
On 01.04.2010 22:54, Pierre Joye wrote:
are we talking about having a thread safe PHP or parallel-like
features available in user land?
The sooner needs some love to be actually true, while most of the
issues come from external libs. The later makes little or no sense.
We're talking about
Hi!
Clearly, with namespace support making class names shorter, we come back
full circle where some class names collide with reserved words, thus we
are forced to become creative with class names:
That might go away if we agreed to give up on case-insensitive class
names (which btw don't
hi,
On Thu, Apr 1, 2010 at 9:18 PM, Stanislav Malyshev s...@zend.com wrote:
Hmm... Interesting issue. Without namespaces filter() obviously would be
Filter's ctor, as class names aren't case sensitive now, remember? But with
namespaces it gets tricky. Can we say filter() is still the ctor,
Hi!
Well, I think the question here is more about dropping old style
constructor that case sensitive functions/methods name. I'm in favour
of dropping in php-next.
I don't feel comfortable with dropping class-named ctor altogether (big
BC issue) but dropping it in NS-classes seems to be
Hey Stas,
The other option here is to simply go back to the behavior in 5.3.0
where no notice is raised at all. That is easy to accomplish (its just
removing the notice inside the first if block of
zend_do_begin_function_declaration(). It would also maintain
consistency with 5.2.x.
On Thu, Apr 1, 2010 at 21:33, Stanislav Malyshev s...@zend.com wrote:
Hi!
Well, I think the question here is more about dropping old style
constructor that case sensitive functions/methods name. I'm in favour
of dropping in php-next.
I don't feel comfortable with dropping class-named ctor
Hi!
I don't like this. The behavior should not depend on other methods
being defined. What if you refactored the class and moved the ctor out
to the parent - and the you get a nasty surprise of filter() suddenly
becoming new ctor?
Consider this idea a band-aid. It would basically allow for us
Hi!
The patch is simple: see attached. Doesn't break any tests except for
ns_063 which specifically tests for this particular case. Any objections
to having this in 5.3?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
Pierre Joye wrote:
are we talking about having a thread safe PHP or parallel-like
features available in user land?
The sooner needs some love to be actually true, while most of the
issues come from external libs. The later makes little or no sense.
Something we agree on Pierre.
The first
On 01.04.2010, at 22:38, Stanislav Malyshev wrote:
Hi!
processing, but then the state syncing of the forked background
processing
results with the main thread requires a whole new protocol / switching
to
interprocess communication, which makes such developments
Anyway, do we really have to tell people you don't need it when they
believe that they do?
Python has multithreading and it works reasonably good. People who know
what they are doing can implement really brilliant solutions (think Tornado)
Interesting thing here threads would require (at
Hello Antony,
Thursday, April 1, 2010, 8:52:13 PM, you wrote:
Not to mention that a high-performance multi-threaded daemon written in PHP
is a total nonsense - that's exactly the task C/C++ do much better/faster.
I'd like to have easily written, decently performing multi-threaded
daemon.
And
Hi!
Eve Online in Stackless Python
fmspy.org http://fmspy.org with stackless python
etc.
I don't know how python does it but PHP has a lot of global context, and
sharing this global context between threads, whatever they are (OS
threads, user-space threads, etc.) would be massively complex
On Thu, Apr 1, 2010 at 11:33 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
Eve Online in Stackless Python
fmspy.org http://fmspy.org with stackless python
etc.
I don't know how python does it but PHP has a lot of global context, and
sharing this global context between threads, whatever
Can someone please re-open bug http://bugs.php.net/bug.php?id=49192 . For me
it's not possible, even (or because?) i'm the owner of the bug.
It still exists in 5.3.2 (Win)
Thx
Johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Mar 31, 2010 at 10:25 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
prevented. The short background of what I'm doing is serializing
backtraces
when errors occur so that I can better diagnose bugs my clients report.
But
when a closure is passed as a function parameter
I use pcntl_fork() for writing parallel multi-process applications and it
works pretty well.
Also, you can use shared memory queues to pass messages between processes
(ie msg_get_queue()).
I wrote a little proof of concept library a while ago to demonstrate:
http://github.com/dhotson/Phork
It's
Hi,
I think that if we were ever to implement threading we would be best off
to enable spawning worker threads that have their own context with no
shared data (and therefore no requirement for locking). We could then
have a message passing API between the threads.
Advantages:
- Real
Done,
Best,
Yannick
Le Vendredi 2 Avril 2010 00:06:13, Johannes Mueller a écrit :
Can someone please re-open bug http://bugs.php.net/bug.php?id=49192 . For
me it's not possible, even (or because?) i'm the owner of the bug.
It still exists in 5.3.2 (Win)
Thx
Johannes
--
PHP Internals -
30 matches
Mail list logo
