sys.exec_prefix does not point to folder with pythonw.exe thus introducing inconsistency,e.g. with multiprocessing in QGIS plugins

[mlt]

Multiprocessing python module on Windows platform relies on starting a new process as that platform lacks fork(). Head-on attempt to use that module from, e.g, QGIS plugin results in a launch of another QGIS instance. To circumvent this, ​multiprocessing documentation suggest to use

set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))

however pythonw.exe is shipped in bin/ and not in apps/Python27/ where exec_prefix points to.

[jef]

Hm, just a suggestion. On Linux it's /usr, which also wouldn't work. Anyway, searching PATH would work.

[mlt]

Replying to jef:

Hm, just a suggestion. On Linux it's /usr, which also wouldn't work. Anyway, searching PATH would work.

There is no reason to call set_executable() on GNU/Linux as multiprocessing uses fork() on this platform.

Well, perhaps it was an impulsive decision to file this issue. The main point was that current file system layout does not match typical one on this platform and contradicts the ​manual on multiprocessing. Although the manual says some thing like. I guess it is not a big deal to write

path = os.path.abspath(os.path.join(sys.exec_prefix, '../../bin/pythonw.exe'))
multiprocessing.set_executable(path)

as long as it won't change.

[jef]

Or multiprocessing.set_executable(distutils.spawn.find_executable("pythonw.exe"))

[mlt]

Replying to jef:

Or multiprocessing.set_executable(distutils.spawn.find_executable("pythonw.exe"))

I wonder if there is a danger to pick up wrong python this way as there are common scenarios to have a few python installations and non-OSGeo4W may be on the PATH.

[jef]

Replying to mlt:

I wonder if there is a danger to pick up wrong python this way as there are common scenarios to have a few python installations and non-OSGeo4W may be on the PATH.

OSGeo4W starts off a clean path. So unless you explicitly add your pythons into PATH from within OSGeo4W you should be fine.