When testing bc8afe79 I noticed that the tests were creating and leaking thousands of goroutines, even though Pigosat as a whole uses very few go calls. I tracked it down to this: newMinimizer creates args as m.args = make(chan arguments, 2). I think the channel fills up and goroutines are blocking on send to the channel.
Maybe this is a more general problem. Using a go call in Minimize is a bit overkill. Instead of adding a Join or Wait method to the Minimizer interface that blocks until all calls to RecordSolution have completed and having Minimize call it before returning, just don't use goroutines at all. Generally, RecordSolution will do nothing more than append to a slice or write to a channel. This is not the real speed bottleneck in the code.
[x] Remove use of go in Minimize
[x] Remove requirement that RecordSolution be safe for parallel use
[x] Replace use of channels in optimize_test with simple slices
When testing bc8afe79 I noticed that the tests were creating and leaking thousands of goroutines, even though Pigosat as a whole uses very few
gocalls. I tracked it down to this:newMinimizercreatesargsasm.args = make(chan arguments, 2). I think the channel fills up and goroutines are blocking on send to the channel.Maybe this is a more general problem. Using a
gocall in Minimize is a bit overkill. Instead of adding aJoinorWaitmethod to the Minimizer interface that blocks until all calls toRecordSolutionhave completed and having Minimize call it before returning, just don't use goroutines at all. Generally, RecordSolution will do nothing more than append to a slice or write to a channel. This is not the real speed bottleneck in the code.goinMinimizeRecordSolutionbe safe for parallel useoptimize_testwith simple slices