As probably the biggest culprit of people who cause bugging on this topic, I would just like to add in that it bugs me from the other side that I have been so slow to "get" it. I'm learning much more about blocking and how it's non magical and have come a long way since starting the conversation on this list nearly a year ago and I sincerely appreciate the patience of everyone that has helped me through it (Ben and sri at the top of that list, and I'm sorry that this has caused a desire to end the conversation of the topic). I know that what awaits me on the other side is so worth it! Mojolicious is an amazing framework and I too am bothered by people sticking blame on Mojo when the issue is nothing of Mojo's (and trust me when I say I've never felt that the issue is Mojo's). I don't want to see Mojo slammed or illed for something that it has no hand in whatsoever. What blocking/non-blocking amounts to is a conversation not about Mojolicious but about Perl, the operating system, hardware, and everything else but Mojo.
So... what can be done about it? Perhaps a reading list to say if you're gonna go down this path, read these things, and understand this stuff first. Ben and sri, how can I know what you guys know?? What did you read? Where did you go to school? What project code should I be looking at? And on Nacho's conversation, I've had an extremely similar question fairly recently and I'll try to restate. And, like him, I get it now -- there's no non-blocking magic! But hear me out if you will... (Or leave now lest you rage with anger...) So if I understand Nacho right, he (sorry, assuming gender) wrote an app that doesn't connect and so it just sits and blocks (but what is it *doing* in that blocked state, why is that state blocking?) And he wants to do something about that. As I understand it, his app is not doing anything in that unconnected state, but taking up a process. Isn't that much like Mojo::UserAgent waiting for a response from a web site? Yet M::UA doesn't block. Is the difference that the web site *is* that other process and that it's on another machine and therefore the website is blocked over there while Nacho's blocking code is embedded within Mojolicious and causing blocking within Mojolicious? For the website, M::UA is saying, hey -- take your time (but not too long) and then get back to me when you're done. But in Nacho's case, that process is the very same process as Mojolicious. And therefore, per the reality of the universe, his Mojo app must block because the socket connection that he's talking about is blocking. I wrote a tiny test case not too long ago to illustrate it. I wrote a nice non-blocking Mojo app that worked wonderfully when connecting to google.comor anything else. But, then I threw it a curveball, and I pointed the M::UA routine back at the very same Mojo app that launched the M::UA routine! The route was a method that just slept for 2 seconds. Of course, the whole app blocked! :D This really helped me to get an understanding for blocking code. So, my question was how to make a M::UA that exists for web sites but make one that exists for databases, and for connecting to an NTP server, and for connecting to any old random socket or process? I could really use Ben and sri's brain, here, to help me understand why this isn't possible / doesn't make sense if that is indeed the case. The database is on another process doing things. Why can't Mojolicious say, hey -- take your time (but not too long) and then get back to me when you're done -- just like what M::UA does for websites? Instead, it connects to the database and says, I'm not leaving until you give me an answer!! So, in short, I understand it's not M's fault, and I understand it's not the duty of the M team to provide a world of training on things that have nothing to do with M but instead have to do with electronics in the end! But, since it's one of Mojo's great features, can the team provide some pointers on where we should turn? I, for one, came from a common CGI.pm and PHP world running on nothing but Apache. I didn't have to understand all that stuff. And that's cuz Apache just kicked off some additional processes when necessary. And here I was trying to do these things with Mojo::Server::Daemon!! My new project was doomed from the start with that approach! At the time, I didn't realize that Apache was just redirecting connections to awaiting processes and spawning new ones when necessary. And I likewise didn't realize that Mojo wasn't. That was my lack of Operating System understanding. My bad, 100%. But I'll say this -- I *want* to know it better and be able to use Mojo as intended. Where should I turn? Hope I didn't bother / bore / enrage people too much. Thanks to everyone, and thanks sri for that FAQ addition. It's a start for us non-OS aware individuals! On Wed, Jan 15, 2014 at 3:25 PM, sri <[email protected]> wrote: > Since this same question seems to pop up on a more and more regular >> basis, and honestly it's starting to get on my nerves a bit how often >> people assume that merely using Mojo::IOLoop or running things under >> Morbo or Hypnotoad make things non-blocking... >> > > This has been bugging me too, so i've added an FAQ answer. Suggestions for > making it better are more than welcome, it's a very tricky subject. > > > https://github.com/kraih/mojo/commit/a2fee7f79fd662f15c7534e5bbe50c09fd3648e2 > > -- > sebastian > > -- > You received this message because you are subscribed to the Google Groups > "Mojolicious" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/groups/opt_out. > -- *----------------------------------------------------------------* *Keystone IT made the following notation* *----------------------------------------------------------------* *Email Confidentiality Notice: The information contained in this transmission is confidential, proprietary or privileged and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). * *This message is for the sole use of the intended individual or entity to whom it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited and may subject you to criminal or civil penalties. If you received this transmission in error, please contact the sender immediately at (314) 621-9500 and delete the material from all computers.* -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/groups/opt_out.
