<div dir="ltr">On Wed, Sep 18, 2013 at 1:51 AM, Antony Lee <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:<br>><br>> Hi all,<br>><br>> While I realize that this is certainly tweaking multiprocessing beyond its specifications, I would like to use it on Windows to start a 32-bit Python process from a 64-bit Python process (use case: I need to interface with a 64-bit DLL and use an extension (pyFFTW) for which I can only find a 32-bit compiled version (yes, I could try to install MSVC and compile it myself but I'm trying to avoid that...))<br>

<br>Just use subprocess to start up the 32-bit Python. If you want to use the multiprocessing tools for communicating data, use a Manager server in the 32-bit Python to communicate over a socket.<div><br></div><div>  <a href="http://docs.python.org/2/library/multiprocessing#managers">http://docs.python.org/2/library/multiprocessing#managers</a></div>

<div>  <a href="http://docs.python.org/2/library/multiprocessing#using-a-remote-manager">http://docs.python.org/2/library/multiprocessing#using-a-remote-manager</a><br><div><br></div><div>It is possible that this won't work if the protocol assumes that the bitness is the same between server and client (e.g. struct.pack('Q', ...)), but I suspect this is not the case.</div>

<div><br></div><div>You may also consider writing a small server using pyzmq or similar. I am guessing that you are just calling one function from pyFFTW and getting the result back. A simple REQ/REP server is easy to write with pyzmq. Do you need to use pyFFTW for some specific functionality that is not available in numpy.fft or scipy.fftpack?<br>

<br>--<br>Robert Kern<br></div></div></div>