Heschi suggested a simpler approach, which is LockOSThread on the read loop for FUSE: this would avoid having epoll and FUSE interfering with each other.

I assume that the problem occurs in the call to the epoll_wait system call from the function netpoll in runtime/netpoll_epoll.go. That call ties up the g, m, and p for the duration of the call. I assume that it doesn't matter whether the call is blocking or not; either way, when the kernel tries to call back into the program to run the FUSE code, the FUSE code will stall waiting for a goroutine.

While it seems clearly more likely when GOMAXPROCS is 1, technically there is nothing stopping many simultaneous non-blocking calls to epoll_wait, and if we have enough of them at once the problem will occur at any GOMAXPROCS level.

If I understand the FUSE code correctly, which I probably don't, the FUSE code is running a goroutine that sits in syscall.Read waiting for FUSE requests to arrive from the kernel. So the problem is that we need to permit that goroutine to run even though GOMAXPROCS goroutines are sitting waiting for epoll_wait to return.

If I understand the problem correctly, then I don't see how LockOSThread will help. LockOSThread doesn't permit you to escape from the restrictions on GOMAXPROCS. But, if it works, great.

Your analysis of the FUSE code is correct. Part of the time it sits in a Read waiting for the kernel, the other part, it tries to write back to the kernel.

I havent tried the suggestion yet, going out for dinner now :-) .

I think this would work if the FUSE daemon used syscall.RawSyscall rather than syscall.Read and syscall.Write. But the cost would be that the FUSE daemon would always occupy a GOMAXPROCS slot, so either the user or the FUSE code would have to bump up GOMAXPROCS.

I haven't yet been able to think of a workable fix in the Go runtime.

If there is a way for the os package to detect that a file is on a FUSE filesystem, then we could avoid using the poller for that file. But I don't know of a way to do that.

Let me see if I can make RawSyscall work. Since this affects tests primarily, that's probably acceptable.

FWIW, on Linux you can find out if a file is on FUSE by calling fstatfs on the fd, and checking the f_type field of the result. It does sound like a lot of overhead, since most files arent on FUSE, and some care is needed since fstatfs is also forwarded to FUSE, so you cannot call it from where you call epoll.

We could call fstatfs from newFile in os/file_unix.go. There it would be a normal syscall, so there would be no difficulty in running the FUSE code.

I fixed it by kludging in something that triggers the POLL opcode before the Go runtime has the chance to.

other fuse libraries like the one from @rsc and bazil.org should likely implement something similar.