4 ms·

Actually, the GIL is needed to execute Python code (well, access Python objects). It is released by I/O- or computation-heavy C code, so e.g. SciPy or reading f

• devinj 17y ago
  Pure Python code can do a lot. Large parts of the stdlib are extension modules, and can release the GIL (e.g. one of the tests on the bug tracker used time.sleep()). In practice, if your code is IO-bound, it's doing work in an extension module, and if it's CPU-bound, it should be doing its work in an extension module. So there's actually not a huge problem.
• jey 17y ago
  I stand corrected. And frightened. fork(), here I come!
  • cma 17y ago
    fork() isn't that great for a lot of situations. If you are thinking of taking advantage of your operating system's copy-on-write paging by loading a large chunk of data to be used read-only, forking a bunch of processes, processing the data each processes, and finally, 'reducing' the results of all of the forks into some sort of output, don't bother. What happens is when you read an object in one process, python increments the reference count, thus touching the memory page, thus copying it, thus screwing you. (however, compacting garbage collection turns out to have more or less the same problem)