Throwing a convoluted quick sketch out: maybe we can have something that handles incoming work as a queue, sends panics to a results channel, and monitors for cancellation and panics to interrupt work:

type Processor struct {
	ctx context.Context
	cancel func()
	wg sync.WaitGroup
	startDone chan struct{}
	work chan func(context.Context)
	panics chan *panics.RecoveredPanic
}
func (p *Processor) Submit(fn func(context.Context)) { p.work <- fn }
func (p *Processor) Start() {
	for {
		select {
		case <-p.ctx.Done():
			close(p.startDone)
			break
		case recovered := <-p.panics:
			p.cancel()
			p.wg.Wait()
			panic(recovered) // or send to Wait to throw?
		// TODO maybe have work handling and panic/cancel handling in separate goroutines
		case fn := <-p.work:
			// TODO something more robust like concurrency handling
			p.wg.Add(1)
			go func() {
				defer p.wg.Done()
				recovered := panics.Try(func() {
					fn(p.ctx)
				})
				if recovered != nil {
					p.panics <- recovered
				}
			}()
		}
	}
}
func (p *Processor) Cancel() {
	p.cancel()
}
func (p *Processor) Wait() {
	p.wg.Wait()
	<-p.startDone
}

Hi @iamnoah! Good question. You're not wrong -- there are not many cases for long-lived pools. There is no real need to re-use pools over a long period of time since they are so cheap to create.

Maybe it would be more clear to phrase it as "pools with long-lived goroutines." Consider a situation like listening on two different ports. For each port, a goroutine is spawned to handle new connections. These two goroutines exist for the lifetime of the server. However, if either panics or errors, you might still want to return control to the spawning goroutine to do some cleanup tasks.

Right now, conc doesn't handle this situation well because a panic/error will not return control to the spawning goroutine until all goroutines have exited. If one listener fails and we catch its panic, the second listener will still happily continue listening for all eternity.

IMO, that's the crux of this discussion -- first, whether that's a situation conc can handle, and then whether it's a situation conc should handle. Because I agree: I do not want to introduce features in conc that make it easy to do bad things.

Right now, conc doesn't handle this situation well because a panic/error will not return control to the spawning goroutine until all goroutines have exited.

What is the downside of WithCancelOnError? When I have multiple long-lived goroutines, I need them all to do their own cleanup before doing any final cleanup.

Thread pools are a thing in other languages due to the cost of threads, but a conc pool is not expensive to create

There is no real need to re-use pools over a long period of time since they are so cheap to create.

I meant don't mean long-lived pools in the sense the goroutines themselves are the resource - one example is the one Camden raises, where e.g. one might have some long-lived processes, though like you mention WithCancelOnError can be used for this because if a process fails (or panics #92) the other task will be cancelled and control will be returned to the caller to handle.

However, another example is one where you want to control concurrency and cleanup over arbitrary tasks that might be submitted (as described in the original discussion post). For example, a processor that handles tasks being submitted continuously, such that it can:

• only handle N at a time
• handle tasks failing independently
• signal that all tasks that are currently running should stop
• etc

The original discussion post links a few requests regarding similar use cases that I think are along similar lines where whether conc/pool can/should be used is a bit dubious. #93 (comment) has another good example