Wait() hangs forever if no goroutine was run with Go() about tomb HOT 7 CLOSED

I assume your concern is that "something" might be an empty list.

You can also handle this situation by doing the iteration inside the first goroutine:

t.Go(func() error {
        for _, s := range something {
                t.Go(func() error { ... })
        }
})

It's always safe to fire new goroutines inside any prior goroutine.

from tomb.

I think it would be better for Wait() to just return.

from tomb.

That's by design. The whole point of a tomb is to wait for work to finish, and if we never start the work it will never finish. If we didn't block on the work starting, concurrent calls to Wait might immediately unblock, and potentially lead to code that worked in tests but not in production given different execution ordering.

If you're finding issues with this, the easy rule of thumb is this: don't hand off a tomb if you don't plan on starting the work. If an error happened, return the error and not the tomb. After you give access to the tomb, do start the work eventually since there's logic waiting for it.

That was the design choice and the rationale. We cannot change it now without breaking people's code, so this isn't up for discussion anymore unfortunately.

from tomb.

Understood.

In my code, I therefore do this:

initialized := make(chan struct{})
t.Go(func() error {
    <- initialized
    return nil
})
for _, s := range something {
    t.Go(func() { ... })
}
close(initialized)

This way, I get a dummy goroutine, alive the time to spawn the other goroutines.

from tomb.

Oh, yes, it's simpler this way!

from tomb.

Yeah my use case was similar to @vincentbernat's, i.e.:

t := tomb.Tomb{}
doStuffWhich_MIGHT_EVENTUALLY_InvolveSpawningGoroutines(t)
t.Kill(nil) // I'm fed up and I want to quit gracefully
t.Wait()

I understand this conflicts with the ability of spawning "producers" (t.Go) and "consumers" (t.Wait) in parallel tho.

Not a big deal, as @niemeyer's workaround works too.

from tomb.

I assume your concern is that "something" might be an empty list.

You can also handle this situation by doing the iteration inside the first goroutine:

t.Go(func() error {
        for _, s := range something {
                t.Go(func() error { ... })
        }
})

It's always safe to fire new goroutines inside any prior goroutine.

nice！

from tomb.