[tahoe-lafs-trac-stream] [tahoe-lafs] #1274: eliminate pywin32 dependency

[tahoe-lafs]

#1274: eliminate pywin32 dependency
------------------------------+---------------------------------------------
     Reporter:  davidsarah    |       Owner:  warner                                       
         Type:  defect        |      Status:  closed                                       
     Priority:  major         |   Milestone:  1.8.2                                        
    Component:  code-storage  |     Version:  1.8.0                                        
   Resolution:  fixed         |    Keywords:  pywin32 windows win64 docs-needed news-needed
Launchpad Bug:                |  
------------------------------+---------------------------------------------
Changes (by davidsarah):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:23 warner]:
 > Replying to [comment:21 davidsarah]:
 >
 > > With this patch, we no longer use anything that calls
 > > {{{reactor.spawnProcess}}} (either in test or non-test code). Does
 > > that resolve the problem?
 > >
 > > {{{iputil.py}}} is the only place [in non-test code] where we
 > > previously used {{{getProcessOutput}}} and now use
 > > {{{subprocess.Popen}}}. Note that it is done in a {{{deferToThread}}}
 > > (I'm not sure whether that helps, since the SIGCHLD handler is
 > > process-global).
 >
 > I don't think that resolves the problem (although I need to stare at the
 > code and test it to be sure). The issue was using {{{subprocess.Popen}}}
 > in a twisted program, regardless of whether or not that same program is
 > using any {{{reactor.spawnProcess}}} calls. {{{subprocess}}} is
 > blocking, of course (when you use {{{p.wait}}} or I think
 > {{{communicate}}}), so using it for {{{iputil.py}}} at startup is
 > somewhat excusable but using it anywhere later would be bad.

 Yes, that's why iputil now uses {{{deferToThread}}}.

 > But it may be the case that we won't see any damage from this right now.
 > When/if we start using spawned children at runtime (again, {{{du -s}}}
 > is the best I can imagine right now), we may have to undo this, or live
 > without that feature.

 We would have to use {{{subprocess}}} for those in any case, to avoid
 reintroducing the dependency on pywin32 on Windows (besides the SIGCHLD
 issue).

 This ticket is done, I've tested it on win32 (including starting a gateway
 node and using the WUI to the pubgrid), and Dcoder ran the testsuite
 successfully on win64. Unfortunately, it seems that buildbot depends on
 pywin32, so we can't set up the Windows buildbots without it installed.
 I'll open another ticket for that.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1274#comment:25>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage