1. 6
  1.  

  2. 7

    All within a single Ruby process.

    Or not. I was kind of curious, but when I got to the end I felt like I’d been lied to.

    1. 1

      (Author here.) Sorry to hear that. I tried to write it replicating how we discovered things, where we did start from that faulty assumption they were all in the same process, and only realise there were more than one process later.

      1. 1

        For me it was mostly that the headline was false advertising. I thought I was going to hear about some kind of bizarre Ruby wat and then the whole thing just turns out to be “forking creates unshared copies of things”. Yeah no crap. Well thanks for that insight…

        You don’t have to give away the conclusion in the title, mind, just refrain from active misdirection. In this case I think just leaving out the “Ruby” bit in the title and the emphasis on Ruby in the setup would be enough to set the article straight. The problem did have something to do with arrays after all, but nothing with Ruby – any program that forks, in any language, would exhibit the same behaviour.

        1. 1

          I think there’s a tricky line between laying out the facts and laying out one’s assumptions. You can leave some of the assumptions implicit, and still work through the problem. But when you state right out it was one process, it sounds like something you verified.

          1. 1

            Ah, I see what you mean. That seems like a totally fair point, and something I’ll keep in mind next time I write something along those lines. Thanks for the feedback!

      2. 2

        I think that they had the same object id’s with different attributes should have been a huge red flag that this was related to processes especially since they are using the Unicorn server.

        1. 1

          That was pretty much the point that someone pondered if it was multiple processes, and we remembered Unicorn forks processes out. :-)