@deoxxa what do you think about this?

This actually looks perfectly reasonable. I can't really see anything wrong with it, and I'm sure it fits perfectly for this specific use case, but I'm also not totally convinced that it needs to be a top-level, core API function.

I'm thinking it might be better to integrate context.Context support instead, since that's really emerging as the way to do deadlines and timeouts. That is a larger job though and might not happen anytime soon - it depends on someone putting in the work, and I know that I personally don't have the time spare right now. If/when this happens, I wouldn't want to have two (maybe incompatible or conflicting) ways to do timeouts.

What say ye, @stevenh? Any opinions?

I'm actually not sure - I'm just assuming there could be tricky stuff. It might be as easy as wiring up a handler between context.Done and the existing interrupt channel though. I won't have time to investigate it for at least the next couple of weeks though.

@deoxxa what signature would you like to see? In method Run, for example.

Closing due to age with no feedback