[Python-ideas] Python 3000 TIOBE -3%

[Gregory P. Smith]

On Fri, Feb 10, 2012 at 11:54 AM, Sturla Molden <sturla at molden.no> wrote:
>
> - Windows has no fork system call. SunOS used to have a very slow fork
> system call. The majority of Java developers worked with Windows or Sun, and
> learned to work with threads.
>
> For which the current summary is:
>
> - The GIL sucks because Windows has no fork.
>
> Which some might say is the equivalent of:
>
> - Windows sucks.

Please do not claim that fork() semantics and copy-on-write are good
things to build off of... They are not.  fork() was designed in a
world *before threads* existed.  It simply can not be used reliably in
a process that uses threads and tons of real world practical C and C++
software that Python programs need to interact with, be embedded in or
use via extension modules these days uses threads quite effectively.

The multiprocessing module on posix would be better off if it offered
a windows CreateProcess() work-a-like mode that spawns a *new* python
interpreter process rather than depending on fork().  The fork() means
multithreaded processes cannot reliably use the multiprocessing module
(and those other threads could come from libraries or C/C++ extension
modules that you cannot control within the scope of your own software
that desires to use multiprocessing).  This is likely not hard to
implement, if nobody has done it already, as I believe the windows
support already has to do much the same thing today.

-gps