Unclosed channels and programm exit

[Nigel Vickers]

hi,

I have to refactor a 36k line program written(by me) in 2012.

"waitgroups and bookkeeping" currently account for ca. 20 % of the code. There are edge cases that create real problems.

Is there any way of guaranteeing programs containing goroutines containing unclosed channels will not exit? 

rgds,

Nigel Vickers

[Jesse McNelis]

There is no way.
A program exits when OS.Exit() is called or main() returns.

You need to architect your program so that goroutines communicate to main() that they are done. This usually involves main() blocking on a channel or waitgroup.

[Thomas Bushnell, BSG]

Note that there is nothing wrong with abandoning an unclosed channel. It does not somehow stay around, as long as there are no live references to it. It's perfectly normal to create a channel send on it, and then be done with it.

Thomas

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Vickers]

Hallo Thomas,

Three years ago I would have probably agreed with you. I, unfortunately, chose to protect my "dones" in the waitgroups with an explicit channel close check to prevent "waits" being triggered  before all "adds" had been registered. This I would not do again. 

Rgds,

Nigel

[Peter Waller]

Hi Nigel,

It's difficult without a concrete example to understand the problem you're having. For example this sentence:

> I, unfortunately, chose to protect my "dones" in the waitgroups with an explicit channel close check to prevent "waits" being triggered  before all "adds" had been registered.

I can't convert this to code in my head because I don't know how you personally write your "explicit channel close check", for example.

It sounds like you're doing a common pattern along these lines:

work := make(chan Job)

var wg sync.WaitGroup

go func() {

  defer wg.Done()

  for range work {}

}()

work <- Job{} // some number of times

close(work)

wg.Wait()

What is your complaint precisely? That it's necessary to have WaitGroups? That it's necessary to close(worK)? That you now find after having wrote this code a lot you have repeatedly made the same mistake?

I'd appreciate it if you could elaborate - so far this discussion is cryptic.

Thanks,

- Peter

[Nigel Vickers]

Hallo Peter,

Thanks for your interest. I would like to prevent a misunderstanding. I asked a specific question and received a competent, concrete answer from Jessta. I had been very involved in another project in another language in the last 6 months. My tracking of  developments in Go have been perfunctory. I was trying to get uptodate quickly. My question was one of four that were on my list to check prior to refactoring.  For interest they were: issue 3317 assaignability in ranges over maps of structs, are ranges of map of *structs now safe for concurrent access, are waitgroup adds() guaranteed to be registered before the subsequent done(), and will programs still exit if unclosed channels exist. The short answer to my questions is the state is as of 2011/12, apart from the addition of the race detector in the middle of 2013 if i remember correctly, little has changed here. This is not a criticism or a problem.  When refactoring we will probably begin by constructing a registration/deregistration process for long running goroutines to ensure programs do not exit when processes are in a waiting state. 

thanks again for your interest,

Rgds,

Nigel