News for hackers. Stuff that matters.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by finiteloop on Thursday September 10, 2009 @02:57PM (#815906)
CherryPy is multi-threaded, so I am not sure what you are saying is correct. There are two types of servers: multi-threaded, multi-process. Tornado is multi-process. If your server is multi-threaded, it uses all of the cores without additional processes.

CherryPy did max out the CPU on all of the cores in the load test, so I think it was a fair test.

Re:Tornado: FriendFeed's non-blocking Python web server is n... by dowskitest on Thursday September 10, 2009 @03:26PM (#815977)
If you ran a single CherryPy instance, I don't see how that is possible. The Python global interpreter lock prevents a single process from making use of multiple cores.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by jnoller on Thursday September 10, 2009 @03:36PM (#816010)
No, it doesn't. I/O bound tasks can heavily use multiple cores just fine using threads.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by TimothyFitz on Thursday September 10, 2009 @08:05PM (#816481)
If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by jnoller on Thursday September 10, 2009 @09:30PM (#816603)
I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threaded app like a message-passing app and you have a much simpler life.

I'm intimately familiar with the limitations of python threads - and right now I'm the maintainer of the multiprocessing module, which is the process-based "reply" to the stdlib threading module.

Re:Tornado: FriendFeed's non-blocking Python web server is n... by TimothyFitz on Sunday September 20, 2009 @03:53AM (#832875)
I wasn't trying to claim you don't understand python, simply that the only way to be CPU bound on multiple cores with a single python process (as is claimed) is to be running non-pure python code that unlocks the GIL before doing CPU intensive work.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by pwmanagerdied on Friday September 11, 2009 @09:10PM (#818461)
<3 multiprocessing, <3 you.
Re:Tornado: FriendFeed's non-blocking Python web server is n... by illumen on Friday September 11, 2009 @05:12AM (#817064)
Can python use mutiple cpus/cores with threads? Short answer no. Long answer, yes for some things.

Even cpu bound tasks can release the GIL to do processing(for non python api tasks).