php-general Digest 3 Nov 2012 22:09:51 -0000 Issue 8030
Topics (messages 319658 through 319661):
Re: Creating an Advanced Form
319658 by: Matijn Woudt
Re: Multithreading for OOP PHP
319659 by: Alex Nikitin
319660 by: Dotan Cohen
Java guru?
319661 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Op 3 nov. 2012 02:12 schreef "tamouse mailing lists" <
tamouse.li...@gmail.com> het volgende:
>
> I'm sorry. This code just makes me weep.
>
> Let's just take a quick look at this line here:
>
> > $rsSearch = mysql_query($sqlSearch);
>
> You have not supplied a database connection, so mysql_query will fail.
> Further, you have not even checked the result to *see* if it failed.
Have you ever used mysql in this form? It works perfectly. Having something
like or die(mysl_error()); is recommended, atleast for debugging, not for
production where you should check the return value and silently fail.
- Matijn
--- End Message ---
--- Begin Message ---
Threading doesn't increase complexity? Spoken truly like somebody who has
not had to actually write, test and debug proper, high performance threaded
code. Please tell me how threading doesn't increase complexity of any data
structure?
I may agree if you talk about php running in cli, but then the very choice
of using php is arguable, you want to thread your console apps, write them
in a language that is threaded. That once again brings up the point that
that is not the market that is meant to be addressed. As far as your phone
goes, again why would you want to run even more threads, if you have 24
threads on your system, you will configure Apache to run 24 threads, each
of you which will serve a request in parallel which will make your server
capable of handling significant load. As far as php side goes, it's a
problem of design of the apps. Just because people decided to go through
hoops to use the threaded model doesn't mean that it is any faster than
writing to the same thing in event driven model, event driven way is
sometimes much faster than threads. Don't blame the language, blame the
poor dev who made it harder on themselves... There are plenty of big and
well performing systems online that pull data from many a locations on the
back end and still manage to serve it to you in less than 2 hundredth of a
second without the need for threading server side code. That's because they
are designed well and implemented well as a system.
Finally another thing to consider is how the operating systems deal with
high amounts of threads, how different architectures deal with them, while
Linux is pretty good about threads, other systems have significant
problems. Php is meant to run on all of them so you choose the model that
works for all.
Lastly I am sorry, but massively parallel architecture for general
computing is still about 10 years out. That's where parallel processing
design will be bore efficient and beneficial. When we have that, and
programmers learn massively parallel design, maybe then we will have a need
for parallel php (pphp?) for now, there is no need, only poor design.
--- End Message ---
--- Begin Message ---
> As far as php side goes, it's a
> problem of design of the apps. Just because people decided to go through
> hoops to use the threaded model doesn't mean that it is any faster than
> writing to the same thing in event driven model, event driven way is
> sometimes much faster than threads.
I'm on both sides of the fence on this one. Imagine the database
operation (not necessarily a SELECT statement) that could take an
arbitrarily long time to complete. PHP should be able to hand that off
to another thread and be done with it:
$dbOpertation = dbThread($sql)
$dbOpertation->start();
Currently, we've got to to write an alternative file dbOperation.php
and call it via exec(), complete with shell-escaping arguments and all
the dangers that go with that:
exec('dbOperation.php'.escapeshellarg($sql));
Now who knows what escapeshellarg() will do to my precious
hand-crafted SQL so I'll have to debug and test that as well. Wait
until you see what that does to your single quotes, and you are in a
world of hurt if your SQL contains literals that also happen to
contain escaped quotes. I don't even know what other characters
escapeshellarg() will mungle, it is not mentioned in the fine manual
so I can either go read the source or start experimenting. And I
happen to be a hobbiest sysadmin, what happens to the poor PHP dev who
doesn't even quite understand the shell or think to escape the
arguments. The prevalence of PDO for simple queries even further
removes many (novice) PHP devs from thoughts of escaping
> Don't blame the language, blame the
> poor dev who made it harder on themselves... There are plenty of big and
> well performing systems online that pull data from many a locations on the
> back end and still manage to serve it to you in less than 2 hundredth of a
> second without the need for threading server side code. That's because they
> are designed well and implemented well as a system.
That is either naive or trolling. You either know very well that some
database operation cannot be completed in n/100 of a second, and we
haven't even started to talk about curl or other potentially
long-running operations.
> Finally another thing to consider is how the operating systems deal with
> high amounts of threads, how different architectures deal with them, while
> Linux is pretty good about threads, other systems have significant
> problems. Php is meant to run on all of them so you choose the model that
> works for all.
I see. Due to a Windows deficiency my PHP-on-*Nix code should suffer.
Are you not aware that some PHP features are available on some OS but
not others? Or that function differently by OS? Seriously, it looks
like you are trolling.
> Lastly I am sorry, but massively parallel architecture for general
> computing is still about 10 years out. That's where parallel processing
> design will be bore efficient and beneficial. When we have that, and
> programmers learn massively parallel design, maybe then we will have a need
> for parallel php (pphp?) for now, there is no need, only poor design.
What? i don't know what you mean by "massively parallel architecture"
but it certainly has no relevancy to the PHP dev who wants to run a
long SQL query.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
Hi gang:
Anyone here a Java guru?
If so, please contact me privately -- I have a question.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
