Go by Example: Timers and Tickers

http://mmcgrana.github.com/2012/09/go-by-example-timers-and-tickers.html

by craigkerstiens • 14 years ago

65 17 14 years ago

mmcgrana.github.com

zemo2• 14 years ago

also time.After: http://golang.org/pkg/time/#After

So what I personally find interesting about this code is how it just... asychronously kicks off arbitrary functions. It reads like scripting except it isn't.

I ask out of curiosity: are there other statically typed languages where you can do stuff like this? Java has Futures, but those are far more heavyweight. Clojure has concurrency constructs which are pretty close, but Clojure is dynamic. I only know a little bit of Haskell, so there might be something like this in there.

thebigshane• 14 years ago

C# now has `async` and `await`, not the same thing, but similar.

Also I'm sure there's about a dozen C++ libraries that will do it.

throwaway54-762• 14 years ago

Rust (another "systems language of the future") has a lightweight syntax for spawned "tasks", I think. But I'm far from a Rust expert.

burntsushi• 14 years ago

This is true. Rust also provides more compile time safety (a lot more actually), but it comes at the cost of complex semantics.

chime3• 14 years ago

I used time.After recently to timeout a net.Dial call if it doesn't connect within 0.1s (it's an intranet app, connection time should be < 0.01s). While that solves my problem of not waiting too long for net.Dial, I wish there was a way to cancel a running go func() call somehow.

I want to read data from a remote port every second, with a 0.1s timeout. Any longer and I can treat it as a failure. If I put ReadRemotePort() in a forever loop with Sleep(1 second), even though the timeout will cause a failure as expected in 0.1s, there will be go func() threads still active until net.Dial has timed out. So at any given time, I could have 180 go func() calls just waiting for net.Dial to timeout at 3 minutes. I still haven't found a way to avoid this.

krasin• 14 years ago

Do these sleeping goroutines add any measurable cost in terms of RAM or CPU?

james4k2• 14 years ago

From http://research.swtch.com/gotour

Q. What are the limits to scalability with building a system with many goroutines?

The primary limit is the memory for the goroutines. Each goroutine starts with a 4kB stack and a little more per-goroutine data, so the overhead is between 4kB and 5kB. That means on this laptop I can easily run 100,000 goroutines, in 500 MB of memory, but a million goroutines is probably too much.

For a lot of simple goroutines, the 4 kB stack is probably more than necessary. If we worked on getting that down we might be able to handle even more goroutines. But remember that this is in contrast to C threads, where 64 kB is a tiny stack and 1-4MB is more common.

chime3• 14 years ago

I wanted to query 100 remote ports each second. Since it takes less than 0.01s to make a successful call and get the 2-3 bytes of data from each server, I thought doing 100 calls in parallel wouldn't be an issue via goroutines. But if 100 x 180 goroutines are waiting to die any given second when there are prolonged connectivity issues (which are possible in my environment), I don't know how stable the app would be overall.

problemdomain2• 14 years ago

This annoyed me when dealing with net/http the other day. Really seems like the Go team hasn't spent much time thinking about problems on the client side of connections yet.

drivebyacct2• 14 years ago

This isn't true. First net and net/http are great. Second, there are examples all over the ML (even within the last three days) that shows how to create an http client with a timeout-able Dial() function.

james4k2• 14 years ago

net.Dial is a special case at the moment. It will have natural timeout behavior in the future, just like Reads and Writes do.

See the comment here: http://golang.org/src/pkg/net/dial.go?s=3003:3074#L110

Edit: In practice, this isn't really a problem at all unless you're calling Dial something like a hundred or thousand times a minute and they're all timing out. Goroutines are very cheap. Still, it is an issue and will hopefully be resolved in Go1.1: http://code.google.com/p/go/issues/detail?id=2631

Go by Example: Timers and Tickers

Related Stories