Any way to kill a goroutine?

[Mue]

Hi,

I would like to execute any function with the simple defined signature
func() with a defined tmieout. So my current approach is

func ExecInTime(f func(), ns int64) bool {
inTimeChan := make(chan bool)

// Wrapper function.

wf := func() {
f()

inTimeChan <- true
}

// Timeout function.

timeout := func() {
time.Sleep(ns)

inTimeChan <- false
}

// Now do it and see who wins.

go wf()
go timeout()

return <-inTimeChan
}

So far so good. But if my timeout func wins the original function
naturally continues working in the background. So I would like to kill
it (would be the hard way) or just a better solution. A communication
based solution inside the function f() is btw. not possible.

mue

[Michael Hoisie]

I don't believe there's a way to do this. You could have wf() listen
for a kill message on a channel, and it would just return if it
receives one.

- Mike

[Ian Lance Taylor]

Mue <m...@tideland.biz> writes:

> So far so good. But if my timeout func wins the original function
> naturally continues working in the background. So I would like to kill
> it (would be the hard way) or just a better solution. A communication
> based solution inside the function f() is btw. not possible.

Currently is no way to kill a goroutine, other than sending it a
message over a channel.

Ian

[Russ Cox]

> A communication
> based solution inside the function f() is btw. not possible.

Then no, there's no way to do it.

Killing individual goroutines is a very unstable thing to do:
it's impossible to know what locks or other resources those
goroutines had that still needed to be cleaned up for the
program to continue running smoothly. I don't expect that
ability any time soon.

Russ

[Mue]

Hmm, yes, I already thought so. And the reason is understandable. But
how to implement that some work is been done in the background while
"waiting" for a signal to stop on a channel? My only idea would be a
kind of state machine triggered by a ticker. Any better idea?

Thx

mue

[Russ Cox]

On Mon, Feb 8, 2010 at 11:40, Mue <m...@tideland.biz> wrote:
> Hmm, yes, I already thought so. And the reason is understandable. But
> how to implement that some work is been done in the background while
> "waiting" for a signal to stop on a channel? My only idea would be a
> kind of state machine triggered by a ticker. Any better idea?

Check the channel once in a while to see if it's time to stop.

Russ

[Mue]

OK. But how to check a channel without blocking? A kind of "peek".

mue

[Ian Lance Taylor]

Mue <m...@tideland.biz> writes:

> OK. But how to check a channel without blocking? A kind of "peek".

http://golang.org/doc/go_spec.html#Communication_operators

v, ok = <-c

Ian

[Mue]

Aaah, great, thx. I've already read a lot in the spec as well as the
rest of the docs, but there are always new features I don't know.

So my fun developing in Go can go on. Another plus for my CeBIT talk.
*smile*

mue

[Mue]

You are great. Just integrated this into my supervisor and now it
works exactly as I wanted it.

Once again thx.

mue