X handle FUSE request inline, instead of spawning handleOp

XXX however it does not speedup jacobsa/fuse.

fuseutil/file_system.go

@@ -90,45 +90,49 @@ func NewFileSystemServer(fs FileSystem) fuse.Server {
 
 type fileSystemServer struct {
 	fs            FileSystem
-	opsInFlight sync.WaitGroup
+	serveInFlight sync.WaitGroup
 }
 
 func (s *fileSystemServer) ServeOps(c *fuse.Connection) {
 	// When we are done, we clean up by waiting for all in-flight ops then
 	// destroying the file system.
 	defer func() {
-		s.opsInFlight.Wait()
+		s.serveInFlight.Wait()
 		s.fs.Destroy()
 	}()
 
-	for {
+	s.serveInFlight.Add(1)
+	s.serveOps(c)
+}
+
+func (s *fileSystemServer) serveOps(c *fuse.Connection) {
+	defer s.serveInFlight.Done()
+
 	ctx, op, err := c.ReadOp()
 	if err == io.EOF {
-			break
+		return
 	}
 
 	if err != nil {
 		panic(err)
 	}
 
-		s.opsInFlight.Add(1)
-		if _, ok := op.(*fuseops.ForgetInodeOp); ok {
-			// Special case: call in this goroutine for
-			// forget inode ops, which may come in a
-			// flurry from the kernel and are generally
-			// cheap for the file system to handle
+	// spawn .serveOps, not .handleOp to improve latency, because we
+	// already received FUSE request and want to handle it as fast as
+	// possible, i.e. now, without first putting handleOp into go scheduler
+	// queue. see e.g. https://github.com/golang/go/issues/15110 for details.
+	//
+	// improving FUSE request-response latency also improves IO throughput.
+	s.serveInFlight.Add(1)
+	go s.serveOps(c)
+
 	s.handleOp(c, ctx, op)
-		} else {
-			go s.handleOp(c, ctx, op)
-		}
-	}
 }
 
 func (s *fileSystemServer) handleOp(
 	c *fuse.Connection,
 	ctx context.Context,
 	op interface{}) {
-	defer s.opsInFlight.Done()
 
 	// Dispatch to the appropriate method.
 	var err error