D. Dante Lorenso escribió:
Gonzalo Monzón wrote:
I've been developing desktop applications with PHP-GTK since 2002,
far beyond the web script context, and in the more complex projects I
did, was a must to implement multi-process and IPC communication due
to the lack of threading in PHP, as to deal with some issues like
multiple tcp clients, multiple tcp server with a proxy to the
application data, webservices, handling UI, and a lot more stuff,
while doing "realtime" (the more realtime I was able of) processing
of all incoming and outgoing data, for more than 24 hours long
running time. Yes, I was able to be successful with such a
developement after a lot of pain, but it is not likely the most
common usage for PHP. I finally had to implement several parts in C,
embedding PHP, and really, I was not happy of to cope with that, but
I did not have the time to switch to another language as I had to
re-use a lot of existing code that worked smooth with a multi-process
approach, but without the need of so long running time, so many tcp
clients, and so many data... I had to implement data containers in
using C structures, as handling all that data from PHP taken more
than 500Mb of RAM in no more than 8 hours of processing, interprocess
syncronization mechanisms, and a lot more stuff.
Sounds to me like you are in my boat! I have done some similar work
to create a multi-process beast. Here is an OO.o Presenter
presentation I did for the Dallas PHP User's Group back in December of
2005:
http://dantescode.com/docs/DPUG%20-%20PHP%20Server%20Applications.odp
Perhaps this will shed a little light on my very similar solution.
Seems to me we could benefit from having some kind of threading
support in the language to avoid all the headache of each of us
building the same code to solve a similar problem. I'm sure there are
others like yourself.
Dante
Yeah, but I'm pretty sure of that each of us have our unique needs, and
only a complete threading support and safety for PHP and all the
extensions would avoid our headaches... and that's not likely to happen
soon.
Sorry but I don't have a Linux box at hand where to install OO
presenter, perhaps you could send me a pdf so us, poor Windows users,
could have a look at it?
I will tell you more about my story... Sorry for the length but... I
haven't got the time right now to make it shorter. :-)
The application I was talking about is not web-based but a PHP-GTK one,
no server side scripting, only cli, so I guess we are in the same boat,
yes, we are, but with very different needs and approaches.
I'll say in advance that I was not able to use any SQL database server
or web based processing for this application, due to project requirements...
My application was mostly based on GTK timers and UI event callbacks.
For inter-process comunication, I had to implement a lot of different
approaches to ensure the best reliability. Some kind of processing
requiered to use syncronized shared memory, other kind used simple
win32api IPC calls... etc.
Each kind of task requiered different approaches, for little data size
overhead, for fast or low response times, and most of these are lot
easier to implement using multi-threading and simple syncronization
mechanisms, as I do now in my new developement environment, once
switched language for almost all the system, with no more headaches or
over complexities due to not be using the right tool for the job.
I really had to switch language as I was not likely to improve more the
system performance as to be able to evolve in the right way for the
future -and i don't want to thought anymore about memory leaks issues I
had to workaround-. I never thought I would need to evolve my system
like to develop such a "beast": once I finished that development and
start to grasp and worry about what would be the next requirements for
the system, I was afraid of: What will I do if do I must handle not 15
clients but 25? how many tcp servers? and perhaps not 150.000 registers
but 300.000 per hour? yes, these requirements now are real.
Before all these troubles, when my system "only" needed to handle 5
clients, 3 servers, no more than 10 processes, and about 65.000
registers per hour, for no more than 3 hours long, I had almost no
headaches... and was quite happy using PHP... :-)
I thought you people must say I'm a fool trying to use PHP for such a
system... I never thought of developing such a system with PHP-GTK...
until I had to do it for "yesterday" and haven't got the opportunity to
say "NO"... lets do it the right way: use a language not designed for
web scripting... we need multithreading and the speed of compiled code
!! don't care if we need 6 months more for development !!! :-)
Only real support for thread safety can avoid such a nightmare, but that
dont seems to happen until... who knows? PHP 8? :-) I think threading is
really a very hard thing to add to a language designed without taking
care about that in the design principles.
Gonzalo
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
