This thread is very interesting! I remember how the failing channel communication API was very important when we once shipped transputer products. Many of them still run on some ships! And how memory never overflowed. (I have bought an XMOS startKIT and am learning XC these days, for a small private project (aquarium!-))
+47 959 615 06
That is my experience!!
I shall now try the latest 1.4 release of the language to see if there have been any changes to the run time to get rid of the problem I found.
I will let you know
Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Edinburgh EH10 5DT
0131 455 2777
So the memory leak is, arguably, correct behaviour then?
There is no such thing as a goroutine going out of scope, there's no process hierarchy. It's spawned in a flat tree and will continue to block indefinitely. Yes it would be possible for the garbage collector to determine that a channel
send could never succeed on that channel but the semantics of what to do after that are very difficult to specify.
On Sun, 29 Mar 2015 at 22:19 Roger Shepherd <rog@xxxxxxxx
see notes inserted below...
In the example, isn't it the case that with the zero-buffered channel the channel and the grouting go out of scope and should be garbage collected? So there is a bug, as the Stack Overflow post suggests.