Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Wednesday November 25 2015, @10:31AM   Printer-friendly
from the get-this-all-sewn-up dept.

As far as I can remember, PHP has always had a terrible reputation at handling very heavy (or asynchronous) tasks. For a long while if you wanted to parallelize long tasks you had to resort to forking through pcntl_fork which had its own issues, and you couldn't really handle the results of those tasks properly, etc.

As such, a habit has kind of developed where we go straight for more intricate solutions such as queuing (which just delays your task if anything), React PHP, or even using another language altogether. But PHP can do threading, and more importantly it's a lot easier than you probably think.

In this article I'm going to dive into the pthreads extension (short for POSIX Threads). It has been around for a while (since 2012) but I feel like too many people forget it exists or assume it is going to be painful to use – mostly because the official documentation is rather slim about it.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by FatPhil on Wednesday November 25 2015, @11:13AM

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday November 25 2015, @11:13AM (#267953) Homepage
    Generate a simple page which then uses AJAX to populate itself, and whilst to the browser's view it's asynchronous, to the server it's perfectly synchronous - request in, whirr, whirr, clunk, result out, job done, let's forget about that and move on to the next one. The webserver itself will also handle parallelism of the multiple requests. Information sharing between them can be done using something like memcached, or any key-value storage mechanism. And forced dependencies can be handled back in the front end - you don't even make the request for resource quux until both foo and bar have been returned.

    The PHP itself is the worst place for any asynchronous processing. Anyone doing this is doing bad design, even if they're hot-shot code bashers.

    If you're not running the PHP in a webserver environment, then my argument is void, but in that case: *what the heck are you doing*, are you mad?
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 2) by deimios on Wednesday November 25 2015, @11:44AM

      by deimios (201) Subscriber Badge on Wednesday November 25 2015, @11:44AM (#267954) Journal

      While I share the sentiment some people learned coding with PHP. "When your only tool is a hammer you treat everything as if it were a nail" and all that.

      I wouldn't exclude such people from learning good coding practices, even if the circumstances are not exactly the best. In time they will figure out why their current limited approach is flawed and move on to more suitable languages.

      • (Score: 3, Interesting) by FatPhil on Wednesday November 25 2015, @12:11PM

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday November 25 2015, @12:11PM (#267958) Homepage
        One of my biggest "dafuq?!?!?!" PHP moments came only 2 days ago. I was watching a youtube tutorial on how to do some h/w hacky thing, and the slave got commands from the master by polling a file residing a webserver, whilst the controller was a webpage invoking a PHP script which wrote to that command file. Nothing wrong with that, you say, except that the master was wget/curling "http://myserver/test.php" and test.php contained nothing but whatever is PHP for "return the contents of test.txt". The concept that the slave could just wget "http://myserver/test.txt" had never occured to this programmer who wanted to solve even non-problems with the PHP hammer. And the rest of the code was shitty too.

        However, he had the h/w working, and I don't, no matter how shitty his code is; so he wins, and I suck. (This is why I often will re-do tutorials that I've learnt from, so that others can see what I consider to be cleaner solutions, and not have to fight against head-scratching issues.)
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by wonkey_monkey on Wednesday November 25 2015, @01:21PM

          by wonkey_monkey (279) on Wednesday November 25 2015, @01:21PM (#267975) Homepage

          One advantage springs to mind; if he ever decides he wants to provide something more complicated than a plain text file can provide - maybe a different text file at different times of day, or a list of commands generated on-the-fly depending on other server activity - he doesn't have to rewrite the slave.

          --
          systemd is Roko's Basilisk
          • (Score: 2) by FatPhil on Wednesday November 25 2015, @04:21PM

            by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday November 25 2015, @04:21PM (#268042) Homepage
            That can all be done in the PHP script which creates the .txt file from the CGI parameters. An intermediate "here's what he asked for"-to-"here's what we should give him" filter seems overengineering to the extreme. I'm guessing that the guy's only ever executed PHP scripts in his server, and didn't realise you could serve text files too.
            --
            Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by SanityCheck on Wednesday November 25 2015, @02:52PM

          by SanityCheck (5190) on Wednesday November 25 2015, @02:52PM (#268007)

          Hahaha perfect! I seen shit like that too. You would not even believe the piles of turds I stepped int hat were in PHP. I guess I feel vindicated that I reach for python when doing any sort of threaded work. But a lot of code here is in PHP, and IF I have to do use parrelism, I would like to continue with PHP.

        • (Score: 3, Insightful) by Fnord666 on Wednesday November 25 2015, @04:42PM

          by Fnord666 (652) on Wednesday November 25 2015, @04:42PM (#268048) Homepage

          One of my biggest "dafuq?!?!?!" PHP moments came only 2 days ago. I was watching a youtube tutorial on how to do some h/w hacky thing, and the slave got commands from the master by polling a file residing a webserver, whilst the controller was a webpage invoking a PHP script which wrote to that command file. Nothing wrong with that, you say, except that the master was wget/curling "http://myserver/test.php" and test.php contained nothing but whatever is PHP for "return the contents of test.txt". The concept that the slave could just wget "http://myserver/test.txt" had never occured to this programmer who wanted to solve even non-problems with the PHP hammer. And the rest of the code was shitty too.

          Because coding the client software to retrieve and parse a text file results in tightly coupled components. The solution given in the tutorial is significantly more loosely coupled [wikipedia.org] and changes in the server side representation of the data doesn't require matching changes in the client side code. This is a good thing.

          • (Score: 2) by FatPhil on Thursday November 26 2015, @12:05PM

            by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Thursday November 26 2015, @12:05PM (#268289) Homepage
            the slave is now tightly coupled to the output of the 1-line php script, and the 1-line php script is tightly coupled to the format of the text file.

            If anything changes, you still need to change 2 endpoints.
            --
            Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 3, Interesting) by wonkey_monkey on Wednesday November 25 2015, @01:32PM

      by wonkey_monkey (279) on Wednesday November 25 2015, @01:32PM (#267978) Homepage

      Why not do it at the client end?

      Because there isn't always a client end.

      And forced dependencies can be handled back in the front end - you don't even make the request for resource quux until both foo and bar have been returned.

      They could be handled at the client end, but can you trust the client not to request quux until both foo and bar have been returned?

      --
      systemd is Roko's Basilisk
      • (Score: 2) by SanityCheck on Wednesday November 25 2015, @03:00PM

        by SanityCheck (5190) on Wednesday November 25 2015, @03:00PM (#268011)

        Yes that is true, it is not ideal solution for a lot of reason, especially where quux has arguments dependent on foo and bar, not to mention that these arguments might now have to be checked to ensure they were not altered by the client. I think that just makes a Swiss cheese out of your whole system.

        It can work for systems where the user just needs to be authenticated, and you guess he has access to all the resources of a certain level based on their level of access (I do this with some legacy systems), and just add sanity checks for the arguments. If he changes the arguments it won't matter since he could call that function with any arguments and not have any problems during course of normal use of the system (assuming his account has the sufficient level of access).

        If you had to ensure for security reasons that this user can call this function with these particular arguments, then you would just end up having to double check so much crap, usually with database queries galore. You would end up doing foo and bar inside quux again just to ensure that it was a valid function call.

      • (Score: 2) by FatPhil on Wednesday November 25 2015, @04:16PM

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday November 25 2015, @04:16PM (#268039) Homepage
        > can you trust the client not to request quux

        Given that you sent the JS code to the client, if it doesn't do that, it's your code that's borked, and you should pay. Of course, you should handle broken clients with a polite "fuck off", rather than getting your own knickers in a twist.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by wonkey_monkey on Wednesday November 25 2015, @06:34PM

          by wonkey_monkey (279) on Wednesday November 25 2015, @06:34PM (#268091) Homepage

          Given that you sent the JS code to the client, if it doesn't do that, it's your code that's borked, and you should pay.

          I was thinking more of the scenario where something on the client side deliberately interferes.

          --
          systemd is Roko's Basilisk
  • (Score: 5, Insightful) by Thexalon on Wednesday November 25 2015, @12:08PM

    by Thexalon (636) on Wednesday November 25 2015, @12:08PM (#267956)

    As far as I can remember, PHP has always had a terrible reputation at handling anything important or complex.

    It spent 15+ years without any coherent design and a lot of legacy code was written that reflects that lack of design. And to add insult to injury, that legacy code is exactly why it persists. In particular, a lot of web developers are of the viewpoint that Wordpress must be used at all times regardless of what the customer actually needs (mostly because they've never even considered using anything else).

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 1, Disagree) by xav on Wednesday November 25 2015, @12:19PM

      by xav (5579) on Wednesday November 25 2015, @12:19PM (#267960)

      s/PHP has/PHP programmers have/

      FTFY

      • (Score: 2) by TheRaven on Wednesday November 25 2015, @04:51PM

        by TheRaven (270) on Wednesday November 25 2015, @04:51PM (#268050) Journal
        Good programmers can write good code in any language. Bad programmers can write bad code in any language. But good programmers look at PHP, see how insanely hard writing good code would be, and pick a less-bad language. The fact that JavaScript is a less-bad language for server-side programming is a big hint that PHP really should die.
        --
        sudo mod me up
        • (Score: 0) by Anonymous Coward on Wednesday November 25 2015, @08:37PM

          by Anonymous Coward on Wednesday November 25 2015, @08:37PM (#268130)

          php is no worse than any other language, and its one of the easiest for programming web apps, so to all the naysayers out there... get over it already

          it probably suffers from tall poppy syndrome more than anything because some of the largest and busiest websites use it (such as facebook and wikipedia), and people who prefer other languages get all pissy about it

          • (Score: 2, Disagree) by TheRaven on Friday November 27 2015, @11:14AM

            by TheRaven (270) on Friday November 27 2015, @11:14AM (#268615) Journal

            php is no worse than any other language

            That's simply not true. I can't be bothered to explain the myriad things that make PHP worse than any other mainstream language, but fortunately someone else has already done an excellent job [eev.ee]. Most languages have their quirks (JavaScript's weird semicolon insertion and lack of sensible number types, for example), but PHP is unique in being composed entirely from poorly composed quirks.

            --
            sudo mod me up
      • (Score: 2) by Thexalon on Thursday November 26 2015, @03:49AM

        by Thexalon (636) on Thursday November 26 2015, @03:49AM (#268233)

        No, I'm referring to PHP the language. My favorite example of how terrible it is: What happens when an error condition is encountered? The answer is *any* of the following, depending on the exact nature of the error condition:
        - The PHP process seg-faults and dies.
        - An exception is thrown up the call stack that may be caught and handled.
        - The error_handler function, if any is registered, is called. If not, an error message is sent to the output, and execution sometimes is halted.
        - The shutdown_handler function, if any is registered, is called. If not, an error message is sent to the output and execution halted.
        - The function spits a warning out to the user, and then the script attempts to continue, potentially with bad data.
        - The function quietly returns an invalid value that looks extremely similar or even identical to a legitimate value.
        - The function quietly returns a value that isn't remotely like a legitimate value, but provides no information whatsoever about what might have gone wrong. You have to call another function to find out what the error was.

        Compare that to well-designed languages, where what happens when things go wrong is something along the lines of:
        - An exception is thrown up the call stack that may be caught and handled.

        Once you experience those options, the PHP situation seems really truly insane.

        --
        The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 1, Disagree) by Anonymous Coward on Wednesday November 25 2015, @04:18PM

      by Anonymous Coward on Wednesday November 25 2015, @04:18PM (#268040)

      In true PHP style, if something new is available in version 5.3.1, it will have its API changed in 5.3.2 (so calling it like you did in 5.3.1 fails), and it won't be available in 5.4.

      After riding that train a couple of times, I said "fuck PHP".

      • (Score: 0) by Anonymous Coward on Thursday November 26 2015, @08:21AM

        by Anonymous Coward on Thursday November 26 2015, @08:21AM (#268262)

        why didn't you say "fuck $whatever_api_you_were_using"?

        classic case of throwing the baby out with the bathwater

  • (Score: 4, Informative) by Bill Evans on Wednesday November 25 2015, @12:35PM

    by Bill Evans (1094) on Wednesday November 25 2015, @12:35PM (#267966) Homepage
    PHP or no, POSIX threading is not for the faint of heart. It requires clear-headed discipline, an inclination to keep threading layout as simple as possible (but no simpler), and an eye out for gotchas.

    On my bookshelf are two books on pthreads programming: Pthreads Programming, by Nichols, Buttlar, & Farrell, published by O'Reilly; and Programming with POSIX Threads, by Butenhof, published by Addison-Wesley. The O'Reilly book is dangerous, not becaue of what's in it, but because of what's not. To get an idea of what should be in such a book, take a very close look at the Addison-Wesley book. Scattered throughout it are descriptions of easy-to-commit gotchas. These gotchas can be expensive because debugging programs using POSIX threads can take days and days and days. Better not to write the bug in the first place.

    The O'Reilly book is like a four wheel drive vehicle, which is superior to others because you can drive further out into the snow before you get stuck. I imagine that facile columns on the web which invite you to get your feet wet with POSIX threads are similarly dangerous. POSIX threads? Run, don't walk, to the Addison-Wesley book.
    • (Score: 2) by darkfeline on Wednesday November 25 2015, @11:49PM

      by darkfeline (1030) on Wednesday November 25 2015, @11:49PM (#268180) Homepage

      I am of the opinion that traditional threading is a dead end anyway. Calling UNIX "do one thing" subprocesses asynchronously is much less likely to create bugs, or as a more general rule, using functions with no external dependencies or side effects, akin to strict functional programming.

      The trick is to move away from classic procedural definitions of problems to functional definitions, especially in computer science education.

      For example, summing up calculations:

      sum = 0
      for i in range(1, 100):
              sum += calc(i)

      This takes 100 sum operations, 100 calc operations in runtime, whereas

      sum(map(calc, range(1, 100)))

      this can theoretically run in 1 calc operation and 1 sum operations runtime, since it is clear that all of the calc()s can be run in parallel, and the sum()s can be done as the calc() results finish asynchronously.

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 2) by Bill Evans on Thursday November 26 2015, @02:21AM

        by Bill Evans (1094) on Thursday November 26 2015, @02:21AM (#268213) Homepage

        I am of the opinion that traditional threading is a dead end anyway. Calling UNIX "do one thing" subprocesses asynchronously is much less likely to create bugs

        Almost always subprocesses are better. Even where there has to be ongoing communication between the mother process and the daughter process, using a pty is cleaner than using pthreads: cleaner in that the processes do not share their heap memory, thus making bugs easier to isolate. The only time I use pthreads is in the (rare) case where speed of execution is an issue. I think the most recent time was about six years ago.

  • (Score: 3, Informative) by bart9h on Wednesday November 25 2015, @12:45PM

    by bart9h (767) on Wednesday November 25 2015, @12:45PM (#267967)

    PHP is still a thing.

    (you can mod me a troll now)

    • (Score: 2, Insightful) by barrahome on Wednesday November 25 2015, @01:28PM

      by barrahome (3580) on Wednesday November 25 2015, @01:28PM (#267977) Journal

      Like it or not PHP is one of the major languages around there, anyone complain about a language, but do they have or do plan to make their own? i'm sure that is a NO. Haters gonna hate. Long Live PHP!

    • (Score: 4, Funny) by pgc on Wednesday November 25 2015, @02:55PM

      by pgc (1600) on Wednesday November 25 2015, @02:55PM (#268010)

      TIL 'TIL'

  • (Score: 2) by engblom on Thursday November 26 2015, @06:32AM

    by engblom (556) on Thursday November 26 2015, @06:32AM (#268251)

    PHP lacked from the very beginning any kind of design. It was just a "perl simplifier", that slowly grew to become a popular tool for making dynamic sites. Even today you see a lot of strange things inside of PHP because it lacked a design from the very beginning. Things are inconsistent and some things are just not thought through at all.

    There are other programming language better suited if you need parallelism in your code. My own favorite is Clojure that is designed from the beginning to make multi-threading simple. Then there are alternatives like Erlang. Actually Wikipedia got a long list of programming languages doing concurrency and PHP is not mentioned there: https://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_languages [wikipedia.org]

    • (Score: 0) by Anonymous Coward on Thursday November 26 2015, @08:25AM

      by Anonymous Coward on Thursday November 26 2015, @08:25AM (#268264)

      slowly grew to become a popular tool for making dynamic sites

      and there are very good reasons for that... perhaps you should investigate them

      or if php is so terribly designed, maybe someone should inform facebook and wikimedia foundation