On Wed, Aug 17, 2011 at 10:57, ⚛ <0xe2.0x...@gmail.com
> On Aug 17, 12:36 am, Russ Cox <r...@golang.org
>> goroutines are not garbage collected.
> This is an interesting problem. The Go run-time currently implements a
> partial garbage collection of goroutines - when it detects that all
> goroutines can be "garbage collected" it reports a deadlock and
> terminates the whole program.
> Generally, if a goroutine is waiting on a resource (that is: waiting
> for the resource to change its state), and the run-time detects that
> the program has no way of changing the resource's state, then the
> goroutine will block forever.
> Option 1: Some people will say that a forever-blocked goroutine should
> be silently removed by the garbage collector.
> Option 2: Some people will say that it is a run-time error, because a
> goroutine is an active entity. When a goroutine wants to terminate, it
> willingly exits from its main function. Until it exits from its main
> function, it doesn't want to be terminated and therefore an error
> should be reported when the run-time detects the goroutine is blocked
We're not likely to do either of these.
If a program is blocked forever, there is
very little point to letting it continue to
sit there. If a single goroutine is blocked
forever, things are much less clear-cut.
It is also very hard to tell that a single
goroutine is blocked forever in most cases.
Option 1 makes debugging too hard.