goroutine

Golang app using sync.WaitGroup & channels never exits

由 自闭症网瘾萝莉.ら 提交于 2019-11-30 17:05:42
问题 I use sync.WaitGroup , defer wg.Close() and wg.Wait() to wait for my goroutines to complete. The program do wait, but it never exits. This is my program (runnable): package main import ( "fmt" "io" "log" "net/http" "os" "sync" ) var symbols = []string{ "ASSA-B.ST", "ELUX-B.ST", "HM-B.ST", } func main() { fmt.Println("fetching quotes...") fetchedSymbols := make(chan string) var wg sync.WaitGroup wg.Add(len(symbols)) for _, symbol := range symbols { go fetchSymbol(symbol, &wg, fetchedSymbols) }

golang http timeout and goroutines accumulation

由 一个人想着一个人 提交于 2019-11-30 16:25:27
I use goroutines achieve http.Get timeout, and then I found that the number has been rising steadily goroutines, and when it reaches 1000 or so, the program will exit Code: package main import ( "errors" "io/ioutil" "log" "net" "net/http" "runtime" "time" ) // timeout dialler func timeoutDialler(timeout time.Duration) func(network, addr string) (net.Conn, error) { return func(network, addr string) (net.Conn, error) { return net.DialTimeout(network, addr, timeout) } } func timeoutHttpGet(url string) ([]byte, error) { // change dialler add timeout support && disable keep-alive tr := &http

Difference between the main goroutine and spawned goroutines of a Go program

由 浪尽此生 提交于 2019-11-30 15:29:30
When creating a server using gRPC , if I start the gRPC server in the main process, it can deal with as many as requests (thousands) from clients. However, if I start the server as a goroutine, it can only handle some requests (hundreds) and after get stuck. I have tested and confirmed this with a very simple example, google.golang.org/grpc/examples/helloworld. Is it because spawned goroutines stack size is very small (2Kbytes), and the main goroutine's much larger? What's the difference between the main goroutine and spawned goroutines? Example link . Modified parts of the example as follows.

Let golang close used channel after all goroutines finished

由 扶醉桌前 提交于 2019-11-30 15:17:44
I am trying to run a number of goroutines which will give their results to a channel. I need a good way to let channel close after all goroutines are done. My first try is to close it after spawn all go routines but I think somehow the channel is closed before all goroutines can send their results. for i:=0; i<=10;i++{ go func(){ result:=calculate() c<-result }() } close(c) for result:= range c{ all_result=append(all_result, result...) } Then, my second try I come up with counting a thread and close it after no thread is running. for i:=0; i<=10;i++{ go func(){ atomic.AddUint64(&go_routine

Is this because the go compiler optimized the code?

由 社会主义新天地 提交于 2019-11-30 04:15:26
问题 package main import "time" func main() { i := 1 go func() { for { i++ } }() <-time.After(1 * time.Second) println(i) } The output is always 1 . However it's absolutely that 1s is enough for the for loop to go over many many times. I think the i in the closure is the i in the main func. See the code below. package main import "time" func main() { i := 1 go func() { for { i++ println("+1") } }() <-time.After(1 * time.Second) println(i) } After many lines of "+1", the output is exactly a great

Explain: Don't communicate by sharing memory; share memory by communicating

由 醉酒当歌 提交于 2019-11-30 00:16:23
I wonder what is the most down to earth explanation of this famous quote: Don't communicate by sharing memory; share memory by communicating. (R. Pike) In The Go Memory Model I can read this: A send on a channel happens before the corresponding receive from that channel completes. (Golang Spec) There is also a dedicated golang article explaining the quote. And key contribution is a working example also by Andrew G. Well. Sometimes too much talking around .... I have derived from the Memory Spec quotation and also by looking at the working example this: After a goroutine1 sends (anything) to a

Difference between the main goroutine and spawned goroutines of a Go program

由 主宰稳场 提交于 2019-11-29 22:44:55
问题 When creating a server using gRPC , if I start the gRPC server in the main process, it can deal with as many as requests (thousands) from clients. However, if I start the server as a goroutine, it can only handle some requests (hundreds) and after get stuck. I have tested and confirmed this with a very simple example, google.golang.org/grpc/examples/helloworld. Is it because spawned goroutines stack size is very small (2Kbytes), and the main goroutine's much larger? What's the difference

Let golang close used channel after all goroutines finished

由 大城市里の小女人 提交于 2019-11-29 21:03:18
问题 I am trying to run a number of goroutines which will give their results to a channel. I need a good way to let channel close after all goroutines are done. My first try is to close it after spawn all go routines but I think somehow the channel is closed before all goroutines can send their results. for i:=0; i<=10;i++{ go func(){ result:=calculate() c<-result }() } close(c) for result:= range c{ all_result=append(all_result, result...) } Then, my second try I come up with counting a thread

Does the goroutines created in the same goroutines execute always in order?

由 隐身守侯 提交于 2019-11-29 15:35:24
问题 package main func main() { c:=make(chan int) for i:=0; i<=100;i++ { i:=i go func() { c<-i }() } for { b:=<-c println(b) if b==100 { break } } } The above code created 100 goroutines to insert num to channel c, so I just wonder that, will these goroutines execute in random orders? During my test, the output will always be 1 to 100 回答1: What you observe as "random" behaviour is, more strictly, non-deterministic behaviour. To understand what is happening here, think about the behaviour of the

Reading values from a different thread

由 十年热恋 提交于 2019-11-29 12:03:54
I'm writing software in Go that does a lot of parallel computing. I want to collect data from worker threads and I'm not really sure how to do it in a safe way. I know that I could use channels but in my scenario they make it more complicated since I have to somehow synchronize messages (wait until every thread sent something) in the main thread. Scenario The main thread creates n Worker instances and launches their work() method in a goroutine so that the workers each run in their own thread. Every 10 seconds the main thread should collect some simple values (e.g. iteration count) from the
订阅 goroutine