4 ms·
Are goroutines really that lightweight that this could handle thousands of simultaneous connections? If so, go is even cooler than I thought. If not, is there e
by apgwoz 17y ago
Are goroutines really that lightweight that this could handle thousands of simultaneous connections? If so, go is even cooler than I thought. If not, is there epoll/kqueue support yet?
- jbarham 17y agoYes, goroutines are that lightweight. Rob Pike's introductory tech talk has a demo where he runs a program w/ 100,000 communicating goroutines in 1.5 seconds on a Mac laptop. See the slides at http://golang.org/doc/go_talk-20091030.pdf http://golang.org/doc/go_talk-20091030.pdf, page 34.
- wmf 17y agoYou have to be careful how you use them. Many green-threaded runtimes convert blocking I/O to non-blocking, but it appears that Go does not. If you have N goroutines blocked on I/O, it looks like Go will use N+1 pthreads to support them; thus a goroutine-per-connection model with blocking I/O is basically the same as the old thread-per-connection model (as used by Varnish or the Apache thread MPM). This stuff isn't entirely clear to me, so maybe someone from Go land can clarify.
- oconnor0 17y agoI think the intent is to multiplex the goroutines on some smaller set of threads. From the language FAQ (http://golang.org/doc/go_lang_faq.html http://golang.org/doc/go_lang_faq.html): "The idea, which has been around for a while, is to multiplex independently executing functions - coroutines, really - onto a set of threads."