runtime: new scheduler doesn't deadlock if you import net

[alberts]

What steps will reproduce the problem?

http://play.golang.org/p/7OCMNqMLzk

What is the expected output?

throw: all goroutines are asleep - deadlock!

What do you see instead?

with tip, it doesn't exit. you see:

SIGQUIT: quit
PC=0x41d301

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc2000000c0)
/home/alberts/go/src/pkg/runtime/zsema_linux_amd64.c:165 +0x2e
sync.(*WaitGroup).Wait(0xc20006a1c0)
/home/alberts/go/src/pkg/sync/waitgroup.go:107 +0xf2
main.main()
/home/alberts/k.go:11 +0x5c

goroutine 2 [syscall]:

goroutine 4 [select (no cases)]:
main.func·001()
/home/alberts/k.go:8 +0x18
created by main.main
/home/alberts/k.go:10 +0x4c

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which version are you using?  (run 'go version')

go version devel +67fc3cb0d3aa Mon Mar 04 14:54:36 2013 +1100 linux/amd64

Please provide any additional information below.

it worked fine with 1b4b6a694b1c (revision just before the scheduler update)

[dvyukov]

Comment 1:

The minimal reproducer is:
package main
import _ "runtime/cgo"
func main() {
    select {}
}
And the culprit is "runtime: allow cgo callbacks on non-Go threads"
https://code.google.com/p/go/source/detail?r=1d5a80b07916cd123d1aa4ef2ae04400f29ac6f6.
Now that C can callback into Go, consider the following scenario.
Go program loads a dynamic library that creates a background thread, Go program blocks
solely waiting for callbacks from C. This looks like a valid scenario now, and old
scheduler would just kill the program immediately. The new scheduler properly waits for
the potential callbacks.
So it looks like a correct behavior to me. However, of course, it's a pity that now it's
impossible to detect deadlocks when import "runtime/cgo" or "C".
What do you think?

[alberts]

Comment 2:

Makes sense. Sadly, it feels like this really degrades the whole deadlock detector
experience, since anything that imports net has this issue.
In our project it's every single binary because stuff at the lowest level imports a log
package that imports net, and we also have some cgo packages that we need for some
Linux-specific stuff.
I know it's probably even worse, but how about a specific function in the runtime or
runtime/cgo package that starts this goroutine? That way only the 1% of people that
really need it will have to pay this cost? I don't think net's cgo parts even do
callbacks?
Or maybe there's a way to start the goroutine the first time C calls back into Go?
Probably not.

[dvyukov]

Comment 3:

It was that way always. net package starts background polling goroutines that
effectively disable the deadlock detector. Also if you have any background
goroutines/times, the deadlock detector is effectively disabled. Also the most dangerous
deadlocks are the ones that do not happen yet (potential deadlocks).
So I am not sure how much it's worth fixing in this form.
It would be awesome to implement a deadlock detector for partial and/or potential
deadlocks, but there is not theory exist for that.

[rsc]

Comment 4:

This has always been this way and like Dmitriy I don't see a way to do better.

Status changed to Unfortunate.

[dvyukov]

Comment 5:

This issue was closed by revision 34c67eb.

Status changed to Fixed.