Commit 59a13571 authored by Kirill Smelkov's avatar Kirill Smelkov

X handle FUSE request inline, instead of spawning handleOp

XXX however it does not speedup jacobsa/fuse.
parent 2f654264
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment