>It is utterly clear that the random wait is not intrinsic to the logic - it was only added for demonstration to simulate varying duration of requests.
I wasn't talking about the random wait at all. I was talking about
for range time.NewTicker(time.Second).C {
fmt.Println("Results: ", results)
}
>You can simply comment out the println and just pick the first results[0].
When should we look at results[0]? There needs to be some notification that results[0] is ready to be looked at. Similarly with all the rest of the results.
>Frankly, the above satisfies all primary goals. The rest is just nitpicking - without a formal specification of the problem one can argue all day.
I guess we have to disagree. From my reading of the blog post it was pretty clear what Chris wanted, and the code you provided didn't meet that.
As soon as results[0] is ready he wants to print it. Then as soon as results[1] is read he wants to print it. Etc. Not waiting till the end to print everything, and not printing anything out of order.
If results[i] must be printed only AFTER print of results[0]...results[i-1], then you effectively need to wait for max of (time to compute results[0]...results[i]), since even if results[i] is computed earlier you can't print it out if results[0]..results[i-1] are not available. If result[0] takes the longest compute time, then you will definitely need to wait till the end.
Frankly, a simple sequential for loop seems to the simplest solution here :)
Anyways, I think this: https://go.dev/play/p/lFBpzUVVzUj satisfies all the constraints. Only look at the output with the "(main)" prefix, the other prints are for elucidation.
package main
import (
"fmt"
"math/rand"
"time"
)
type Result struct {
value int
computed bool
consumed bool
}
func main() {
args := []int{5, 2, 4, 1, 8}
results := make([]Result, len(args))
signal := make(chan bool)
signalCount := 0
slowSquare := func(arg int, index int) {
randomMilliseconds := rand.Intn(1000)
blockDuration := time.Duration(randomMilliseconds) * time.Millisecond
<-time.After(blockDuration)
square := arg * arg
results[index] = Result{value: square, computed: true}
fmt.Printf("(#%d) Squared %d, index=%d, result=%2d, duration=%s, sending signal. \n", index, arg, index, square, blockDuration)
signal <- true
}
for i, x := range args {
go slowSquare(x, i)
}
for {
if signalCount == len(results) {
break
}
<-signal
signalCount++
for i := 0; i < len(results); i++ {
if !results[i].computed {
break
}
if !results[i].consumed {
fmt.Printf("(main) Squared %d, index=%d, result=%2d\n", args[i], i, results[i].value)
results[i].consumed = true
}
}
}
}
That code has a race condition. One goroutine can modify an element of results at the same time a different goroutine is reading it. Running with `go run -race` detects the race.
This can be fixed with a mutex.
Now that we've got working code (with the mutex), we have to ask: have we proved Chris wrong? I don't think so. Chris never said it's impossible to implement this in Go. Chris just said that implementing it in Go is uglier than using an array of promises in some other language. And I think this code is uglier than an array of promises.
Although I think I disagree with Chris. He says that an array of channels is significantly uglier than an array of promises. I don't think so. I think an array of channels is fine (and is easier to understand than the signal, signalCount, computed, consumed, +mutex code).
package main
import (
"fmt"
"math/rand"
"time"
)
func main() {
args := []int{5, 2, 4, 1, 8}
results := make([]chan int, len(args))
slowSquare := func(arg int, index int) {
randomMilliseconds := rand.Intn(1000)
blockDuration := time.Duration(randomMilliseconds) * time.Millisecond
<-time.After(blockDuration)
square := arg * arg
fmt.Printf("(#%d) Squared %d, index=%d, result=%2d, duration=%s, sending signal. \n", index, arg, index, square, blockDuration)
results[index] <- square
}
for i, x := range args {
results[i] = make(chan int, 1)
go slowSquare(x, i)
}
for i := 0; i < len(results); i++ {
fmt.Printf("(main) Squared %d, index=%d, result=%2d\n", args[i], i, <-results[i])
}
}
Yes, I didn't quite get why he wanted a solution without multiple channels..it is clearly the best way. The only other option without multiple channels is to use one of the atomic types: `sync/Atomic.Int32` (to avoid the mutex) and then a single channel for signalling.
I wasn't talking about the random wait at all. I was talking about
>You can simply comment out the println and just pick the first results[0].When should we look at results[0]? There needs to be some notification that results[0] is ready to be looked at. Similarly with all the rest of the results.
>Frankly, the above satisfies all primary goals. The rest is just nitpicking - without a formal specification of the problem one can argue all day.
I guess we have to disagree. From my reading of the blog post it was pretty clear what Chris wanted, and the code you provided didn't meet that.