News for hackers. Stuff that matters.
Re:The Python GIL Visualized by kilowatt on Tuesday January 05, 2010 @01:29PM (#1032887)
Just because your frontend uses XY,000 KB of memory doesn't mean that worker processes have to too. The working set size for a fresh Python 2.6 run on my Windows 7 box is 6,620KB. See Chrome for a good example of this approach :)
Re:The Python GIL Visualized by tentonova2 on Tuesday January 05, 2010 @01:34PM (#1032894)
Chrome's approach was not chosen because of its general purpose suitability as a multi-core processing model, but because of the security advantages of relying on OS process separation in a web browser.

Chrome is a very specific use case with unusual requirements. If you take anything away from the Chrome example, it would be that securely replicating the functionality easily available from shared-memory threads in a multi-processing model is both very complicated and not very portable.

Re:The Python GIL Visualized by thorax on Tuesday January 05, 2010 @01:52PM (#1032935)
We're talking about the multiprocessing package/modules in Python:

http://docs.python.org/library/multiprocessing.html

It uses fork under the covers, so small worker processes aren't an option for that module (unless we forego interpreter embedding entirely which isn't the point).

There are other techniques for spawning processes to do some external process work, but those, of course, need entirely separate plumbing.