• Zygo (unregistered) in reply to dkf
    dkf:
    Oh lovely! Side effects from a GET, just what we always needed...

    ScriptAlias / /www/cgi-bin/launch_nucular_missiles.php

  • Eam (unregistered) in reply to Aaron
    Aaron:
    In other words, on a busy shared web host, you could end up, on average, with less than one thread tossing out those e-mail messages, whereas if you'd just done it in a single-threaded loop, the worst performance you'd see is one thread.
    For real. Not to mention that Apache will probably spawn a new PHP process for every incoming request (unlike ASP.NET and most Java app servers, which keep engine instances in memory and reuse them).

    You'd have to be doing something computationally mental on a server with a LOT of processor cores to make up for all the overhead you're introducing with this ridiculous method of "multithreading". And if you require communication between the "threads", it gets even better. Of course, the monkeys on your average PHP forum will probably recommend using the file system or database for IPC.

    "I need to ask my friend for advice on whether to hammer the nail with a glass bottle or old shoe. Should I use cans-on-a-string or a carrier pigeon to call him?"

  • (cs) in reply to Aaron
    Aaron:
    BCC exists for a reason.

    How do you think BCC works under the hood?

    Hint: The SMTP server doesn't care what's in the To, Cc, Bcc header, it directs mail based on the RCPT TO command. Which, to my knowledge, only accepts a single address at a time.

  • Grant D. Noir (unregistered) in reply to Eam
    Eam:
    Aaron:
    In other words, on a busy shared web host, you could end up, on average, with less than one thread tossing out those e-mail messages, whereas if you'd just done it in a single-threaded loop, the worst performance you'd see is one thread.
    For real. Not to mention that Apache will probably spawn a new PHP process for every incoming request (unlike ASP.NET and most Java app servers, which keep engine instances in memory and reuse them).

    Ever heard of apache-modules? No?

  • barfman (unregistered)

    1)Some of the comments here are bigger WTFs than the original article. But, to be fair, I've seen code written in other languages that failed to multi-thread in an equally dismal manner. The difference is that it was written by people with many of years of experience.

    A:You know, since PHP probably doesn't have a way to do multithreading B:Actually it does: http://ca.php.net/manual/en/function.pcntl-fork.php

    A:Beautiful multi-threading. If I would have known a loop creates threads by itself it would have saved me so much time! Wow this was enjoyable B:It's not the loop that creates threads by itself. The loop writes img tags the the HTML. The browser will request each image from the server. These requests are executed in different threads on the web server so it really kind of does work. The amount of threads that will be parallelly executed depends on how many simultaneous requests a given web browser will make.

    Reading these 3 comments back to back is truly a WTF! :P

  • Transcend (unregistered)

    (Some of the comments here are simply scary). The problem here is that of task division; there are two ways to do this right: the cheap way is a close analogue to what is presented here (but will not be interrupted if the client loses his connection, presses stop, surfs with images off, or just surfs away) by an fopen of an uninterruptible script handling the sub-task; the better way is to dump the receiver list in a database, start cron on the sub-task, have it generate mail for every record it can prune off the list, and have it turn off cron when done.

    The solution is dangerous, but it has nothing to do with HTTP 1.1 suggested limits or raw stupidity; it just involves an unreliable browser in the critical role of marshaling the central core of the process. The real solution, though, looks quite a lot like what is being proposed here.

    (Captcha: Burned)

  • fluf (unregistered) in reply to aaron

    Clever indeed. Stupid and not actually multi-threaded though, it's more like multi-processed.

  • (cs) in reply to Grant
    Grant:
    For those who didn't catch the WTF, the HTTP 1.1 spec states that client programs should only make two connections to an existing server (8.1.4 Practical Considerations) so you'll only get two threads!

    <wink />

    So jack it up!

    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPer1_0Server"=dword:0000000a
"MaxConnectionsPerServer"=dword:0000000a
  • Adam (unregistered)

    Someone said this looked clever. I'll admit that I've had similar requirements before (but not exactly like this)

    For example, image size generation on the server takes a while, but I need thumbnail and display sizes immediatly, but icons and details can take a while to generate.

    The solution I take to do this is to have php shell out to another script, or application or whatever I want. If I want it to block the script then I run it in the foreground and wait for response.

    If I want it in the background and not have to leave the user waiting, I run the shell scripts as a background shell process, essentially multitasking (image generation is now happening in the background).

    Anyways, my solution might not be perfect, but at least it doesnt require client side code to initiate the threads, as everything is handled on the server. Although it still kind of has the parent.php child.php mentality to it.

  • Antony Mouse (unregistered)

    But unlike the mean-old folks who would often answer my questions (“RTFM, idiot!”), I don’t believe in picking on those trying to learn.

    RTFM is not about picking on anyone. It means what it means.

    In fact, today, it’s time to pick on someone trying to teach…

    That someone has just answered in a funny and at the same time more or less correct way, trying to implant the clue.

  • - (unregistered) in reply to NameNotFoundException
    NameNotFoundException:
    Until then he had triggered the daily status mails to the customers by calling a web page

    I once maid a web application where you could click on a link and send out a report. Later I was asked if this could be done automatically each morning... so what did I do?

    I set up a crontab with a wget call to the web page :-)

    Later I learned that PHP had a CLI mode, so I switched of course.

    Don't get me wrong. I don't normally use PHP for command line tools, but sometimes a web application needs to be updated automatically (such as generating reports), and why mix languages when PHP can do the work fine?

    I also use Perl, Python and a bit of Java of course, depending on the task.

  • - (unregistered) in reply to -
    -:

    s/\bmaid\b/made/g and other corrections...

    Please ignore spelling errors :-)

  • Huh (unregistered)

    for($i=1;$i<=10;$i++){ echo "[image]"; } ?>

    Okay... this is just wrong.. basically even if it DOES happen to call it ten times, it is calling the same start to finish through the get vars.. so you are emailing the same 1000 clients ten times over.

  • - (unregistered) in reply to Random832
    Random832:
    Aaron:
    BCC exists for a reason.

    How do you think BCC works under the hood?

    Hint: The SMTP server doesn't care what's in the To, Cc, Bcc header, it directs mail based on the RCPT TO command. Which, to my knowledge, only accepts a single address at a time.

    Yes, but once you send the mail to the server, PHP doesn't have to care what happens. The SMTP server probably uses some sort of threading to send mails anyway.

  • Andrew (unregistered) in reply to SlyEcho
    SlyEcho:
    kingofnothing44:
    Beautiful multi-threading. If I would have known a loop creates threads by itself it would have saved me so much time! Wow this was enjoyable
    It's not the loop that creates threads by itself. The loop writes img tags the the HTML. The browser will request each image from the server. These requests are executed in different threads on the web server so it really kind of does work. The amount of threads that will be parallelly executed depends on how many simultaneous requests a given web browser will make.

    That is not parallel processing. A parallel algorithm should have at least two distinct tasks that later join to form a final result. Computers can do this using either threads or processes.

    So, this person's PHP explanation was wrong on a few counts.

    1. His algorithm sent N independant e-mails.
    2. He wasted effort on Web client/server back-and-forth.
    3. He ran whole processes for each trip through the loop.
    4. He made N separate processes (or threads) when one would suffice. 5**) Webservers, such as Apache, support either threads or processes. So, who knows whether this PHP code will even use threads!?!
  • (cs) in reply to Random832
    Random832:
    Aaron:
    BCC exists for a reason.

    How do you think BCC works under the hood?

    Hint: The SMTP server doesn't care what's in the To, Cc, Bcc header, it directs mail based on the RCPT TO command. Which, to my knowledge, only accepts a single address at a time.

    It's irrelevant. Using BCC requires invoking exactly one connection to the SMTP server, even if there are 1000 commands. Individually mailing 1000 messages requires 1000 connections to the SMTP server.

    (Yes, I know, not all mail servers let you distribute to 1000 recipients at a time. You get the idea.)

    Of course BCC isn't magic, the addresses still have to be issued individually as per the protocol, but don't underestimate the overhead of actually creating and destroying all the connections (not to mention the repeated HELOs and so on).

  • Andrew (unregistered) in reply to Mr. Garrison
    Mr. Garrison:
    Despite what our teachers may have said, there is such a thing as a stupid question.
    There are no stupid questions, only stupid people!

    Yes, there are. See the Charles Babbage quote here.

  • greyfade (unregistered)

    I think the same person answered my own question about general multithreading at Slashdot recently. I simply want a good resource that will help me learn how to apply multithreading techniques in a shared memory space. What's the first reply? "Here's how you do it in PHP!"

    I wanted to hit something.

  • bighusker (unregistered) in reply to mol
    mol:
    Evo:
    thread.php?from=1&to=1000; DROP TABLE mailing_list_table

    no problem, mysql_query executes only first sql statement...

    The real WTF Is that nobody called him out on that board.

  • CastrTroy (unregistered) in reply to Nodren
    Nodren:
    so i dont really understand, is the wtf that php doesnt support multi-threading... being that its really just a web based scripting language(not really necessary for that anyway) or that someone wanted it to be threaded, and came up with a fairly reasonable solution(aside from using the forking extension mentioned above

    I'm not so sure what exactly would be wrong with having a multithreaded PHP script. Sure you wouldln't want to send anything to the response stream, but as long as you were careful, and gathered the data correctly at the end, you may be able to speed up execution. Think about it this way. Somebody does a search on your website. So, you start the search thread, that goes and gets the search results from the database. In the mean time, you load all the templates for displaying the data, and once the search is complete, you just fill in the templates. So you don't have to wait for the search to complete to load all your templates. Simplistic example. I'm sure some better examples could be found.

  • (cs)

    Thank you! This has to be one of the most entertaining WTFs I've read in a long time! The approach is brilliant! Here's someone who's taken an impossible problem, and solved it in their own, urm... unique way. I love it!

  • AdamK (unregistered) in reply to Aaron
    Aaron:
    I'm pretty sure Apache pools, though. Just about every web server does. The original post about creating a new thread for every instance was probably just badly worded. Or wrong.
    Not really. Polling is an easiest, but the most resource hungry way to do. IIRC Apache can use several different methods, depending on an underlaying OS capabilities. Usually it is a form of waiting for some kind of messages (on Linux it might be inotify for example).
  • K (unregistered) in reply to CastrTroy
    CastrTroy:
    I'm not so sure what exactly would be wrong with having a multithreaded PHP script. Sure you wouldln't want to send anything to the response stream, but as long as you were careful, and gathered the data correctly at the end, you may be able to speed up execution. Think about it this way. Somebody does a search on your website. So, you start the search thread, that goes and gets the search results from the database. In the mean time, you load all the templates for displaying the data, and once the search is complete, you just fill in the templates. So you don't have to wait for the search to complete to load all your templates. Simplistic example. I'm sure some better examples could be found.

    Another example would be a PHP script connecting to a web service. Then the script could have multiple connections if it needs to. I have often seen web services that are too fragmented, where you have to combine 2 or 3 sources to get the information you need. If this can be done at the same time, you should use threads

  • Paul Harrison (unregistered) in reply to Matt

    Not being able to use multiple threads is a wonderful, sensible language limit.

    My mental picture of Java is a tricycle -- not too quick, but hard to hurt yourself with -- with a chainsaw called threads bolted to the front.

    I'm imagining with ColdFusion (I haven't had the pleasure of using this), they've added an extra wheel or two for extra stability. One hopes they also took off the chainsaw.

    People who actually understand threads are rare and strange and twitch a lot. They tend to wake in a cold sweat in the middle of the night and start raving about race conditions.

    Let your database handle concurrency.

  • Miksu (unregistered) in reply to Paul Harrison
    Paul Harrison:
    People who actually understand threads are rare and strange and twitch a lot. They tend to wake in a cold sweat in the middle of the night and start raving about race conditions.

    Thank you, that's definitely going into my quote collection :)

  • wtf (unregistered) in reply to aaron
    aaron:
    i actually think that this is a pretty clever way to do this. wouldnt say a good way, but you have to admit that it is clever.
    no it's not, because any self-respecting web browser would not open more than a few (2? not sure) simultaneous connections for the "images" anyway. so they'll still have at most a couple "threads".

    firefox with the fasterfox extension and specific settings might indeed open many connections at once, but i'm not too sure about this - how does it combine with http keep-alive and/or pipelining which would negate this and again force the requests to wait for each other and reuse the connection?

    and even if he does get many connections, lots of default php configurations use auto-started file-based sessions with locks so a second script from the same session will hang around and wait for the earlier scripts to finish...

  • MH (unregistered) in reply to Paul Harrison
    Paul Harrison:
    Not being able to use multiple threads is a wonderful, sensible language limit.
    Maybe if we talk .bat files or shell scripts. However any modern language for building applications needs threads to be useful. This is because most applications today are event driven, network enabled and based on provider-consumer architecture. All three of these features are very cumbersome to handle and tend to make an application much less interactive if written in a single threaded language where you have to wait for all calls to finish or poll-loop until done. Languages of today often have lots of nifty help classes/features that make threading quite easy and safe, once properly understood.
    Paul Harrison:
    My mental picture of Java is a tricycle -- not too quick, but hard to hurt yourself with -- with a chainsaw called threads bolted to the front.

    Java vs C++ benchmarks: http://www.freewebs.com/godaves/javabench_revisited/

    So assuming Java is 2-5 times slower than C++ on low level tasks, I'd rather compare them as Java == Volvo vs C++ == Hotrod. Java/Volvo for the lower speed and for safety design protecting the users when things go wrong. C++/Hotrod for optimum speed but intended to be used only in designated places and by experts, who are aware of the risks.

    (Sorry for any bad grammar. English is not my first language.)

  • (cs) in reply to MH
    MH:
    (Sorry for any bad grammar. English is not my first language.)

    This being later than 1985, that's the only reason you can get away with using the phrase "hot rod" in a serious discussion.

  • (cs) in reply to SlyEcho

    ...which is generally only two.

  • MH (unregistered) in reply to Someone You Know
    Someone You Know:
    MH:
    (Sorry for any bad grammar. English is not my first language.)

    This being later than 1985, that's the only reason you can get away with using the phrase "hot rod" in a serious discussion.

    Intended to write Ferrari first, but the problem is that a Ferrari, unlike c++, have quite a lot of safety build in today. Hot rod was what i came up with as a very fast machine that is quite unsafe to crash with =)

  • NiceWTF (unregistered) in reply to Dmitriy Kropivnitskiy
    Dmitriy Kropivnitskiy:
    The point here is that he is using the web server as his threads framework. [..] what exactly is the problem with that code?

    Next week he'll discover that he needs to share some data between the threads, and the week after that he'll discover this great thing called "race conditions", and find that there's no language mechanism to deal with them.

    Though I fully expect someone will now come up with a synchronization primitive for PHP in this thread.....challenge starting in 3..2..1..

  • (cs) in reply to -
    -:
    Random832:
    Aaron:
    BCC exists for a reason.

    How do you think BCC works under the hood?

    Hint: The SMTP server doesn't care what's in the To, Cc, Bcc header, it directs mail based on the RCPT TO command. Which, to my knowledge, only accepts a single address at a time.

    Yes, but once you send the mail to the server, PHP doesn't have to care what happens. The SMTP server probably uses some sort of threading to send mails anyway.

    If you read the post I was replying to, you'd see that it was claiming that sending multiple emails would get you spam blacklisted (presumably by your local SMTP server, since [ESPECIALLY if they're sent as individual emails] the recipient systems don't know how many people you're sending it to) somehow, when in reality you're sending the same number of emails whether you put all the addresses in To:, Cc:, Bcc:, or send them individually with only one address each in the To: header.

    Addendum (2007-08-14 09:07):

    Aaron:
    It's irrelevant. Using BCC requires invoking exactly one connection to the SMTP server, even if there are 1000 commands. Individually mailing 1000 messages requires 1000 connections to the SMTP server.
    Or it requires running /sbin/sendmail 1000 times to submit the messages into the local queue. And while the post doesn't go into detail on exactly how the emails are sent, we can speculate that he most likely uses the built-in mail() function, which does exactly that on unix systems.
  • Anonymous (unregistered)

    Not really a 'naive' question, unless he said 'mod_php' instead of 'php'. It's perfectly valid to use PHP in commandline apps, in which case, the following package might solve the problem:

    http://pecl.php.net/package/threads

  • Everah (unregistered) in reply to bighusker
    bighusker:
    The real WTF Is that nobody called him out on that board.
    We generally reserve call outs for folks that have more than one post. That fella posted one time in the form of a response three years after the last activity in that thread, which on our boards has a tendency to be either spam or someone that thinks they have an answer that they have yet to test but want to share while posting links in their signature to their ad-ridden web sites. It happens more often than people realize in our community.

    As an aside, the thread/fork discussion did pick up within hours after that WTF post, and continued a bit afterward. Of course, the guy that posted that WTF never bothered to show himself around our community after that.

    CAPCHA: burned (seems almost appropriate, doesn't it?)

  • hk0 (unregistered) in reply to webhamster
    webhamster:
    ... I converted a number of Perl scripts to run in command line PHP. ... If you don't know what you're doing then you shouldn't be using it.

    You shouldn't be using it, then. WHY WOULD YOU EVEN DO THAT, REINVENTING THE WHEEL? PHP is already exactly Perl, only worse.

    And when you're done with that, I need you to take dictation in triplicate for me on lined and unlined paper.

  • Matthew (unregistered) in reply to rycamor
    rycamor:
    And yes, there ARE quite legitimate uses of PHP commandline scripts, especially for cron jobs involving databases, or for simple system management scripts.

    PHP for system management scripts? Are you mad? The only excuse for ever using PHP from the commandline outside of a web app is if you absolutely require a certain library that isn't available for other languages. For example, I once had to write a commandline script in PHP because I required the FX.php library (has to do with Filemaker Pro). If I could have done it with Perl or Ruby or Python or a shell script, I would have in a heartbeat. PHP is such a braindead, ugly language that is specifically designed for web pages. Use the right tool for the job, for most things outside of dynamic web pages, PHP is not it.

  • davros (unregistered) in reply to Russ
    Russ:
    (I don't have to worry about silly language limits like this since I code in ColdFusion...)

    hahahaha! funniest thing I've read in ages, coldfusion!?!!!

  • Derick (unregistered) in reply to Lingerance
    Lingerance:
    Russ:
    You know, since PHP probably doesn't have a way to do multithreading

    Actually it does: http://ca.php.net/manual/en/function.pcntl-fork.php

    forking new processes is not multi-threading, it's multi-processing

  • Arioch (unregistered) in reply to nixen

    you're saying that the php engine creates a new thread for every incoming request?!? Not PHP, but Apache. Not for request, but for connection. And only Apache 2.x creates thread, Apace 1.x creates process.

    However avoiding this is what simplistic-servers-with-reverse-proxies like nginx were created for. Or, for really heavy load, yaws.

  • blah (unregistered)

    everyone has missed the true wtf.. the submitter must have been searching for "Multi threaded PHP" on Google to find a 4 year old forum thread about it.

    captcha: dreadlocks

  • poop (unregistered)

    http://www.caucho.com/resin-3.0/quercus/index.xtp

    this is real guys. the php code is straight compiled to java-bytecode. I tried threads with it, works like hell.

  • Mr Steve (unregistered) in reply to davros
    davros:
    Russ:
    (I don't have to worry about silly language limits like this since I code in ColdFusion...)

    hahahaha! funniest thing I've read in ages, coldfusion!?!!!

    x2 ;]

    I've never quite worked out why anyone uses CF. Hosting for it is $$$$ and there's not exactly a huge community making nice open sourced software, frameworks, etc for it.

  • Kuba (unregistered) in reply to SomeCoder
    SomeCoder:
    rycamor:

    And yes, there ARE quite legitimate uses of PHP commandline scripts, especially for cron jobs involving databases, or for simple system management scripts.

    That's very, very true.

    However, there are also nearly infinite other methods you can use besides a command line PHP script that are much more suited to the task.

    I just know a guy who thinks that PHP is the end all, be all of languages and uses it for everything. There are some things it's meant for and some things it really isn't. In my mind, command line cron jobs can be done with other things besides PHP.

    To be frank, and I don't mean to be inflammatory, just practical and fact-oriented, PHP's only positive is its wide deployment. The libraries and their ekhm, consistent, ekhm, set of aptly named functionality is something to be despised, and undoubtedly a source of a s***load of errors, er, I mean fun in the industry. The backend, including Zend, seems perfectly good, but the libraries are just plain unprofessional. Heck, they are unprofessional when compared to say Win32 API, which in itself is not something to be overly proud of.

    I don't know Perl's libraries (at least those considered to be core-well developed ones), so I can't comment on that. Assuming they are OK, Perl as a language would be a decent-enough replacement for PHP for my use -- the core language features are a reasonable mix, and a good enough approximation of Lisp ;) What I do know is that, having coded a few small web applications in PHP, I won't ever do it again if I have the control over where it's gonna be deployed.

    For most part, whatever web-based I have to do these days is done in Lisp, and I don't really see a reason to use PHP given that any Unix-y Lisp worth its salt can easily call native C library functions. I wish Allegro CL-based application servers were as widely deployed as PHP, it'd make the damn thing cheaper. As it is, I don't use it, for low-volume work SBCL is good enough for me.

    Heck, I write embedded software for tiny microcontrollers (as in 4kB RAM tiny) in a Lisp dialect. At least then I don't need hacks like assembly-time macros written in assembly. Yuck. And they teach with that :( <rant>It takes, IMHO, a special sort of insight, to advocate writing domain-specific embedded languages (assembly-time, not run-time) not only in assembly, but actually developing the high-level assembler (HLA) to do just that. That's like doing everything in one's power to avoid Lisp. Oh well...</rant>

    Saying that "PHP is fine for small jobs" is essentially suggesting that peoeple learn something that won't ever be useful if they intend to grow.

    As to the WTF at hand, I see a couple things. First of all, for such an application, once the request gets to the web server there should be no involvement of the requestor (the browser), other than maybe to provide feedback to the user on the progress. Secondly, given that it was asked on the PHP forum we're stuck with PHP, there are proper, if hacky, was of sending as many emails as you wish even in execution-time-limited environments.

    Probably the simplest way to deal with time limits is to emulate continuations in PHP, and have the script exec another one to continue its work, once it has been sending for say 90% of the allotted time. The chain of exec-ing scripts would be fired off from the main script by fork+exec. This would likely be the least WTFy way given the assumed circumstance of being runtime limited - we have to deal with two problems: finishing the original request in reasonable time, and keeping the PHP instances from running out of time.

    A separate script would handle the AJAX or simple refresh side of things for the feedback. The feedback and worker scripts can communicate via some sockety mechanism, or, if allowed, can simply keep the feeback appended to a session-specific file which is then read by the feedback script. Given WTFy nature of PHP itself, that's all there is to it.

    PHP feels like working in bash with more library functions. The available level of expression is about the same.

    Cheers!

  • rycamor (unregistered) in reply to Kuba

    Kuba, I'm the first one to agree that PHP has all sorts of quirks, inconsistencies and odd limitations. People say it's the bastard child of Perl, but I say it feels more like the bastard child of C and Bash. But still, many of the things people DO with software are simple. Writing a script to open a database once a day, run a query, and based on the query save certain files here or there... not so complicated. Ergo if I were advising a PHP developer who just needed such a thing, I would say just do it in PHP. What's the big deal?

    But honestly, many of the WTFs are informational in nature... viz. the inconsistent function naming, or the fact that even fairly knowledgeable people like yourself don't seem to realize that the script time limit can be turned off. In fact, spending a serious amount of time researching all the "I hate PHP" web articles out there, I found that at least 90% of the WTFs were gone somewhere between PHP 4.3 and 5.2.

    Yes, PHP has no elegance. I much prefer the more functional-oriented kinds of languages like Python or Ruby for general scripting, but in spite of all the whining I've seen out there, I've managed to be actually accomplish something in PHP if that's the requirement. Generally it's best to approach PHP as if C had suddenly magically been turned into a scripting language. It's even got something

    BTW, I have to laugh... even IBM is on this game: Develop multitasking applications with PHP V5

    Like it or not, PHP will be gradually coerced into becoming a general language. Sigh... now if they would just add first-class functions, closures, namespaces... ahh never mind! We know that's not in the cards.

  • segmentation fault (unregistered)

    if you need to thread, why are you using php?

  • (cs) in reply to Dmitriy Kropivnitskiy
    Dmitriy Kropivnitskiy:
    I am not entirely sure why are you guys making fun of it. The point here is that he is using the web server as his threads framework. Each time he calls a page in the loop, the web server will create a thread or a fork executing thread.php, so what exactly is the problem with that code? He is just not doing it using internal language mechanisms. Oh, yes, SQL injection is bad, but threading is brilliant (I wouldn't use image tags though).
    (1) Side-effects from GET. (2) "Threads framework?" (3) Never, ever, ever, use threads unless you really need them. (3a) .. and even then, make sure that you, and only you, have control of the threads. (4) SQL Injection. (5) Don't see what's wrong with image tags. Isn;t that what Andreesen forced on Berners-Lee to make the whole despicable WWW thing viable commerically?

    ... er, I've forgotten my point here.

    Oh yes.

    Why would any sane human being want to make PHP scalable? It just isn't. It was never designed to be. It's mighty fine in its own way, but that way is the way it should be left in. If you're expecting the average PHP application to cope with more than fifty or so simultaneous connections, then you've made a bad and business-threatening mistake.

    And even if you do want to make PHP scalable, this is hardly a sensible way to do it.

  • (cs) in reply to Kuba
    Kuba:
    <rant>That's like doing everything in one's power to avoid Lisp. Oh well...</rant>

    Saying that "PHP is fine for small jobs" is essentially suggesting that people learn something that won't ever be useful if they intend to grow.

    <snip/>

    Given the WTFy nature of PHP itself, that's all there is to it.

    PHP feels like working in bash with more library functions. The available level of expression is about the same.

    Cheers!

    Quoting Computer Science at these people isn't going to stop them, you know. But thanks for playing ...

  • Big G (unregistered)

    holey fork...

    what else can I say?

  • Christophe Beyls (unregistered)

    About pcntl_fork(): The process creation functions of PHP must not be used in a web server environment, so in this case it's useless.

    About multithreading in PHP: The web server manages the threads. Apache 1.3 with mod_php was single-threaded. So you can create as many requests as you want, only one will be executed at a time. I don't know about Apache 2 with mod_php, but any web server using FastCGI runs multiple instances of PHP at the same time, so parallelism is possible in this case. Of course this is not what I call "multithreading"...

  • Jørgen Tellnes (unregistered) in reply to qdfqsdfqsdfqsdfqsdf
    qdfqsdfqsdfqsdfqsdf:
    And that shared web host would obviously allow you to inject 1000 mails in the mail server?

    Excellent way for the web host to get blacklisted.

    My webhost allowed me to send > 20 000 huge mails to a GMail-address (mine), and it hasn't been blacklisted anywhere yet. Oh, and yes, GMail really does have all the storage it says it has. :)

Leave a comment on “Multi-threaded PHP ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article