Updates to tomb package

[Gustavo Niemeyer]

Thanks to a change set from Roger Peppe, the tomb package has seen
some improvements in the way its API works.

The functionality is still exactly the same, but the API was changed
in the following ways:

- Renamed Fatal and Fatalf to Kill and Killf.

- The Stop error value is gone. Use nil instead.

- The Err method will now return ErrStillRunning if the goroutine
isn't dead yet, which means a nil return reflects an actual nil Kill call.

- Make zero-value of Tomb good to use, and as a consequence, make
Dead and Dying into methods rather than fields.

The blog post describing the package lives at:

http://blog.labix.org/2011/10/09/death-of-goroutines-under-control

It hasn't been updated with the new API yet, but will be.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

[Jeff R. Allen]

I was surprised when I read the code that the channels are not of type boolean, as that's how I imagined it when reading your post. Can you comment on why the channels are of type "struct {}"?

Thanks for a nice little example of Go-ish thinking.

 -jeff

[Miguel Pignatelli]

On 07/03/12 11:24, Jeff R. Allen wrote:
> I was surprised when I read the code that the channels are not of type
> boolean, as that's how I imagined it when reading your post. Can you
> comment on why the channels are of type "struct {}"?
>

I am not sure about the reason, but could it be because the property of
struct{} taking up no room?

M;

[Gustavo Niemeyer]

On Wed, Mar 7, 2012 at 08:24, Jeff R. Allen <jeff....@gmail.com> wrote:
> I was surprised when I read the code that the channels are not of type
> boolean, as that's how I imagined it when reading your post. Can you comment
> on why the channels are of type "struct {}"?

The values themselves are not important for these two channels, as
they are used merely to flag an event. Besides taking no space,
struct{} informs more realistically the fact there's no actual data
being informed via the channel.

[kortschak]

Each iteration makes this package more elegant.

I have a query though. At the moment it works (by design) as a control for a single goroutine. If Tomb.dead were a waitgroup it could be used to mass control a collection of goroutines. Can you think of any real problems with this modification?

thanks
Dan

[roger peppe]

On 8 March 2012 00:58, kortschak <dan.ko...@adelaide.edu.au> wrote:
> Each iteration makes this package more elegant.
>
> I have a query though. At the moment it works (by design) as a control for a
> single goroutine. If Tomb.dead were a waitgroup it could be used to mass
> control a collection of goroutines. Can you think of any real problems with
> this modification?

It's useful that Dead() returns a channel so it's easy and cheap to
wait in a select for the tomb to finish.

However although the documentation refers to a single goroutine,
it's easy to use it for a collection of goroutines by using a WaitGroup
alongside it.

for example: http://play.golang.org/p/Xh7qWsDPZP

(wouldn't it be nice if play.golang.org knew about external packages?!)

[kortschak]

Yeah. That's very nice. I realised the reason for the chan usage, but hadn't thought through how to get groups - your example should probably go into Gustavo's update of the blog post or the community wiki.

thanks

[Gustavo Niemeyer]

On Thu, Mar 8, 2012 at 08:12, kortschak <dan.ko...@adelaide.edu.au> wrote:
> Yeah. That's very nice. I realised the reason for the chan usage, but hadn't
> thought through how to get groups - your example should probably go into
> Gustavo's update of the blog post or the community wiki.

I'll put the example onto the tomb package itself so that it's visible
in the documentation.

Thanks for suggesting, and thanks to Roger for the sample.