4 ms·

Wow, you're talking about Stackless, something a lot different. >he correct answer would have been the GIL and multiprocessing limited only to blocking IO call

by runT1ME 16y ago

Wow, you're talking about Stackless, something a lot different. >he correct answer would have been the GIL and multiprocessing limited only to blocking IO calls. I'm familiar with the GIL, however I don't think you are. > you would have realized that you spend 95% of your time waiting for IO on most web processes hahahaha. This is funny, because I know why you think this. See, because Python doesn't do multi threading, you spawn up a seperate process for every web hit. Then of course you have to hit your cache servers or DB, hence waiting on IO. See, when you graduate to big kid programming you'll realize that 1997 called and they want their architecture back, and instead it's much better to have a mature platform that handle multiple concurrent web requests from one VM, hence they can share a cache, so no, I don't work on apps that spend 95% of the time in IO because if that is the case you're doing it wrong.

Daishiman 16y ago
Evidently you haven't read or used WSGI, Tornado, or Twisted in any significant form. So Python sucks at multithreading, which doesn't mean that there aren't some very good workarounds, and that multiprocessing works as good as any other place. Btw, if you HAD tried to use Python on any significant way, you would have known that WSGI on Apache recycles the VM for multiple requests, which is the reason why it's suggested to do static file serving outside of Apache within the same server. And, oh yeah, I have yet to hear from anyone except people doing CPU-intensive processing have the programming language be the bottleneck. Congratulations if your system is CPU or network-limited, in which case I'd hope that you're writing something in a lower-level language to handle the situation, but in 99% of large site installations, even if you cache all your IO, it's still going to be the big bottleneck of your system. Seriously, opening a remote socket and sending shit through it is almost always a bigger issue than pushing HTML. Finally, it still doesn't change the fact that some of the biggest web sites are running Python in the back end and they couldn't be happier.

by runT1ME 16y ago

Daishiman 16y ago

Evidently you haven't read or used WSGI, Tornado, or Twisted in any significant form. So Python sucks at multithreading, which doesn't mean that there aren't some very good workarounds, and that multiprocessing works as good as any other place. Btw, if you HAD tried to use Python on any significant way, you would have known that WSGI on Apache recycles the VM for multiple requests, which is the reason why it's suggested to do static file serving outside of Apache within the same server. And, oh yeah, I have yet to hear from anyone except people doing CPU-intensive processing have the programming language be the bottleneck. Congratulations if your system is CPU or network-limited, in which case I'd hope that you're writing something in a lower-level language to handle the situation, but in 99% of large site installations, even if you cache all your IO, it's still going to be the big bottleneck of your system. Seriously, opening a remote socket and sending shit through it is almost always a bigger issue than pushing HTML. Finally, it still doesn't change the fact that some of the biggest web sites are running Python in the back end and they couldn't be happier.