X wcfs: Care to disable OS polling on us

If we don't early-disable it, we can see a situation where when
handling invalidations wcfs calls open("@revX/bigfile/...") to upload
cache data there, go runtime tries to use epoll on that fd, and it gets
stuck as described in the commit referenced in comments.

In particular the deadlock was easy to trigger with nproc=1 environment
(either a VM with 1 cpu, or e.g. under `taskset -c 0`)

Bug reported by @romain.

tox.ini

@@ -5,6 +5,8 @@ envlist = py27-{ZODB3,ZODB4,ZODB5}-{zblk0,zblk1}-{fs,zeo,neo}-{numpy113,numpy114
 # (NOTE NEO does not work on python3 at all)
 # (XXX ZODB5-*-neo are currently failing)
 
+# TODO wcfs ncpu=1, ncpu>1
+
 [testenv]
 deps    =
     # why tox does not get it from extras_require['test'] ?

wcfs/wcfs.go

@@ -1628,6 +1628,20 @@ func main() {
 	//  opened, so when all inodes has been forgotten - we know all wcfs.py clients exited)
 	_ = autoexit
 
-	// serve client requests
-	fssrv.Serve()	// XXX Serve returns no error
+	// serve client requests.
+	//
+	// use `go serve` + `waitMount` not just `serve` - because waitMount
+	// cares to disable OS calling poll on us.
+	// ( if we don't disable polling fs serving can get stuck - see
+	//   https://github.com/hanwen/go-fuse/commit/4f10e248eb for details )
+	done := make(chan struct{})
+	go func () {
+		fssrv.Serve()
+		close(done)
+	}()
+	err = fssrv.WaitMount()
+	if err != nil {
+		log.Fatal(err) // XXX err ctx?
+	}
+	<-done
 }

[Kirill Smelkov]

/cc @romain

[Romain Courteaud]

thanks