• 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)
    Comment held for moderation.
  • 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
    Comment held for moderation.
  • greyfade (unregistered)
    Comment held for moderation.
  • 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
    Comment held for moderation.
  • (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)
    Comment held for moderation.
  • 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
    Comment held for moderation.
  • 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)
    Comment held for moderation.
  • 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
    Comment held for moderation.
  • rycamor (unregistered) in reply to Kuba
    Comment held for moderation.
  • 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 #:

« Return to Article