Thanks for your suggestions. This freeze happens to coincide with a larger
number of cgo calls which in turn most likely do blocking read/write from
sockets. How are those treated by the scheduler?

I am not doing anything FUSE related, nor do I have assembly code. The only
"interesting" stuff is the use of a c library - librados.

In the goroutine dump from SIGQUIT, some stacks are followed by register
dumps. Are those the only ones currently running? All of those are in
runtime: 16 are in runtime.futex, 2 are in runtime.notetsleepg and one in
runtime.gopark, which would make it seem like it was not an un-preemptable
tight loop, but I am not sure how to parse the SIGQUIT output.


> I don't know what is happening with your program.
> This kind of thing can happen if you have a goroutine that is running
> in a tight loop with no function calls or memory allocations.  The
> current Go scheduler is non-preemptive, meaning that nothing will stop
> that loop.  If that loop occurs while holding a lock, it could block
> the entire rest of the program from running.  However, you would see
> this in the stack trace.  This problem with the current scheduler is
> https://golang.org/issue/10958.
> This kind of thing can happen if you are using an in-process FUSE file
> system implemented by goroutines in your program.  The Go runtime
> believes that some system calls, such as pipe or socket, never block.
> If you have somehow set things up so that those system calls enter
> your FUSE file system and depend on some other goroutine running, it
> is possible that that goroutine will never be scheduled.  I don't know
> of any bugs like this at present but they have existed in the past.
> Of course if you aren't using a FUSE file system then this is not the
> problem.
> This kind of thing can happen if you use assembler code to do a
> blocking operation, or if you use syscall.Rawsyscall to call a system
> call that blocks.  That can confuse the scheduler and lead to a
> deadlock.  Don't do that.
> None of these are likely, but you asked for suggestions, and that's
> what I've come up with.
> Ian

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to