An update to the tomb package has just been pushed with the
following changes:
- ErrStillRunning is now ErrStillAlive, to conform to the terminology.
- ErrDying introduced. When the tomb state changes to dying and there's
still logic going on within the goroutine, nested functions and methods
may choose to return ErrDying as their error value, as this error won't
alter the tomb state if provied to the Kill method. This is a convenient
way to follow standard Go practices in the context of a dying tomb.
The blog post explaining the tomb package usage has also been updated
to cover the new API. It has a nice example explaining how to use it:
http://blog.labix.org/2011/10/09/death-of-goroutines-under-control
Please drop a note in case you want some help using it.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I'm not absolutely sure of anything.
Oops, I'll fix that.
> and I want to remind you of the nice multiple goroutine control construction
> that Rog Peppe suggested here some time ago
> (https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/mFjpIuEQH2M),
> for inclusion in the blog or docs.
Will check it out as well, thanks!
I look forward to looking closer at it.
Indeed. In fact, it's time for goneat.org to go away, as mentioned in
the other thread.
I've mentioned the example in the documentation, and have updated the post.
Thanks for all the suggestions,
On Tue, Apr 3, 2012 at 19:03, Jeremy Wall <jw...@google.com> wrote:
> Looks superficially similar to my gosup experiment:
> http://code.google.com/p/gosup/
>
> I look forward to looking closer at it.
Cool, please let me know what you think.
Note that Tomb doesn't attempt to bring the concept of Erlang
supervisors to Go. It's just a very simple building block to
synchronize about the termination of one or more goroutines, and
tracking any potential errors that caused them to stop. This is by
design, in the sense that it won't ever do more than that.