[go-nuts] Design proposal (Go2): Channels and Goroutine cleanup

Ill outline my problem and a solution, I'd appreciate well reasoned
feedback as to why this would be a good idea, or a bad idea.

The problem:

I have a computation pipeline where data flow is simply flowing one way
down a go-routine pipeline through channels.

go1 -> go2 -> go3 -> go4

There is an issue when any of the go-routines experiences an error, leaving
previous goroutines blocked is a memory leak.

To solve this I can either complicate logic by adding a select to each
goroutine send which either sends to the next channel or recieves an error
and panics + recover to terminate the nested call stack, or I can add this
code to each stage:

defer readChannelUntilEmpty(prevStage)

This change means that if any goroutine fails, the previous ones wont be
deadlocked and leaking memory as it is now guaranteed to run to completion.
This logic is far simpler than adding selects to every send, however it's
obvious flaw is whenever there is an error, you are wasting work, moreover,
if the input is an infinite sequence this will fail.

Both of these solutions feel akin to manual memory management to ensure
goroutines dont leak, and if enough goroutines leak in a faulty program,
the whole program will crash eventually. (we invented a GC to avoid this
crap)


Solution:

change all channels into two separate parts:

  readonly,writeonly := make(chan int)

then a write is attempted to the write end of a channel whos read only end
has been garbage collected, the runtime knows there is a deadlock and can
run a panic in the sending goroutine killing it, knowing that it is
deadlocked permantly.

when a read occurs on a channel who has its write end garbage collected,
then either it could be treated as an implicitly closed channel, or a panic
could be raised.

This two sided channel system would make using goroutines far simpler in my
opinion, in the same way that garbage collection makes memory management
easier. I think this idea has been suggested before, but I don't think the
panic on the sender idea has been presented.

Basically deadlocked goroutines are a bug which will crash a process
eventually, so why no make this panic explicit? A program can then add a
recover to the goroutine start if they want to explicitly allow the
goroutines to be garbage collected.



Also, what are the arguments against this? I cant really see a downside,
and can see HUGE upsides. It could even work with existing go channels with
some runtime logic regarding double ended channels and casting them to
single sided channels. Was this overlooked in the original design of Go, or
is there a good reason against it?