goroutine

Golang http server blocks when starts a goroutine of infinite-loop

由 怎甘沉沦 提交于 2019-11-28 13:53:34
As i learned from golang docs, if i set runtime.GOMAXPROCS(8) with a cpu of 8 cores (intel i7), then start a goroutine of infinite-loop, other gorutines should not be blocked because there are engough threads and goprocs. But this is not true when using net/http package, an infinite-loop goroutine will block http server after a few invocations. Can anyone help to explain why ? If i comment the line of "go infinite loop", start client after server, client will output 1000 asterisks; but if i enable the goroutine, client will block after print a few asterisks I have tried add runtime

golang struct concurrent read and write without Lock is also running ok?

由 时光怂恿深爱的人放手 提交于 2019-11-28 12:55:41
concurrentMap() function Have WARNING: DATA RACE , And fatal error : concurrent map read and map write concurrentStruct() have WARNING: DATA RACE, But running ok why the struct can DATA RACE? package main import ( "sync" ) func main() { // concurrentMap() concurrentStruct() // concurrentStructWithMuLock() } type Metadata struct { mu sync.RWMutex // 🔐 key bool } // concurrentStruct 并发操作结构体 // concurrent read and write the struct // go run -race main.go 有 WARNING: DATA RACE，但是可以运行 // go run -race main.go It have WARNING: DATA RACE, But running ok func concurrentStruct() { m := new(Metadata) for

Why does it not create many threads when many goroutines are blocked in writing file in golang?

由 有些话、适合烂在心里 提交于 2019-11-28 08:41:36
As we know in go, a thread may be created when the goroutine has to perform a blocking call, such as a system call, or a call to a C library via cgo. Some test code: package main import ( "io/ioutil" "os" "runtime" "strconv" ) func main() { runtime.GOMAXPROCS(2) data, err := ioutil.ReadFile("./55555.log") if err != nil { println(err) return } for i := 0; i < 200; i++ { go func(n int) { for { err := ioutil.WriteFile("testxxx"+strconv.Itoa(n), []byte(data), os.ModePerm) if err != nil { println(err) break } } }(i) } select {} } When I run it, it didn't create many threads. ➜ =99=[root /root]$ cat

Goroutine execution inside an http handler

由 …衆ロ難τιáo~ 提交于 2019-11-28 05:29:10
问题 If I start a goroutine inside an http handler, is it going to complete even after returning the response ? Here is an example code: package main import ( "fmt" "net/http" "time" ) func worker() { fmt.Println("worker started") time.Sleep(time.Second * 10) fmt.Println("worker completed") } func HomeHandler(w http.ResponseWriter, r *http.Request) { go worker() w.Write([]byte("Hello, World!")) } func main() { http.HandleFunc("/home", HomeHandler) http.ListenAndServe(":8081", nil) } In the above

proper way of waiting for a go routine to finish

由 牧云@^-^@ 提交于 2019-11-28 05:26:37
问题 I wish to know what is the proper way of waiting for a go routine to finish before exiting the program. Reading some other answers it seems that a bool chan will do the trick, as in Playground link func do_stuff(done chan bool) { fmt.Println("Doing stuff") done <- true } func main() { fmt.Println("Main") done := make(chan bool) go do_stuff(done) <-done //<-done } I have two questions here: why the <- done works at all? what happens if I uncomment the last line? I have a deadlock error. Is

How to wait until buffered channel (semaphore) is empty?

由 早过忘川 提交于 2019-11-28 04:21:15
问题 I have a slice of integers, which are manipulated concurrently: ints := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10} I'm using a buffered channel as semaphore in order to have a an upper bound of concurrently running go routines: sem := make(chan struct{}, 2) for _, i := range ints { // acquire semaphore sem <- struct{}{} // start long running go routine go func(id int, sem chan struct{}) { // do something // release semaphore <- sem }(i, sem) } The code above works pretty well until the last or last

How best do I keep a long running Go program, running?

由 谁说胖子不能爱 提交于 2019-11-28 03:48:49
I've a long running server written in Go. Main fires off several goroutines where the logic of the program executes. After that main does nothing useful. Once main exits, the program will quit. The method I am using right now to keep the program running is just a simple call to fmt.Scanln(). I'd like to know how others keep main from exiting. Below is a basic example. What ideas or best practices could be used here? I considered creating a channel and delaying exit of main by receiving on said channel, but I think that could be problematic if all my goroutines become inactive at some point.

Mutual Exclusion of Concurrent Goroutines

由 感情迁移 提交于 2019-11-28 02:04:14
问题 In my code there are three concurrent routines. I try to give a brief overview of my code, Routine 1 { do something *Send int to Routine 2 Send int to Routine 3 Print Something Print Something* do something } Routine 2 { do something *Send int to Routine 1 Send int to Routine 3 Print Something Print Something* do something } Routine 3 { do something *Send int to Routine 1 Send int to Routine 2 Print Something Print Something* do something } main { routine1 routine2 routine3 } I want that,

How does select work when multiple channels are involved?

由 人盡茶涼 提交于 2019-11-27 16:06:46
I found when using select on multiple non buffered channels like select { case <- chana: case <- chanb: } Even when both channels have data, but when processing this select, the call that falls in case chana and case chanb is not balanced. package main import ( "fmt" _ "net/http/pprof" "sync" "time" ) func main() { chana := make(chan int) chanb := make(chan int) go func() { for i := 0; i < 1000; i++ { chana <- 100 * i } }() go func() { for i := 0; i < 1000; i++ { chanb <- i } }() time.Sleep(time.Microsecond * 300) acount := 0 bcount := 0 wg := sync.WaitGroup{} wg.Add(1) go func() { for {

Number of threads used by Go runtime

由 与世无争的帅哥 提交于 2019-11-27 15:14:37
How many threads can the Go runtime (scheduler, garbage collector, etc.) use? For example, if GOMAXPROCS is 10 , how many of those kernel threads would be used by the runtime? Edit: I was reading the rationale for changing GOMAXPROCS to runtime.NumCPU() in Go 1.5. There was a sentence that claimed that “the performance of single-goroutine programs can improve by raising GOMAXPROCS due to parallelism of the runtime, especially the garbage collector.” My real question is: If I have a single-goroutine program running in a Docker container that has a CPU quota, what is the minimum number of
订阅 goroutine