On Wed, Feb 20, 2013 at 12:20 AM, Isaac Jurado <span dir="ltr"><<a href="mailto:diptongo@gmail.com" target="_blank">diptongo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":70">What's the plan for Windows?  Threads or processes?<br>
<div class="im"></div></div></blockquote></div><br>Threads won't help, because update is partly CPU bound and threads will all serialize on the GIL.<div><br></div><div>So if there's to be an answer for Windows, it has to be processes, presumably started via os.spawnv.</div>
<div><br></div><div>I'm in no rush to implement a Windows solution. I don't expect an approach based on the multiprocessing module to be useful, because (a) people do all kinds of perverse packaging things on Windows that are unlikely to work with multiprocessing and (b) the multiprocessing module adds a ton of overhead, so you have to do a lot of work to overcome its communication costs.</div>
<div><br></div><div>(We can't use any of the various "Windows has something sort of like fork(2)" approaches either, because they are all terribly broken.)</div>