Simplify goroutine setup for async task requests

[mehulkar]

This change works, but I see that the total execution time jumps from ~500ms to ~2s though (both FULL TURBO). I can share the test I'm using (in front).

The execution time shouldn't change by much, because execution is closed off before the wg.Wait(), so I don't think this diff is the best either

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
examples-basic-web	🔄 Building (Inspect)			May 13, 2023 5:01am
examples-cra-web	🔄 Building (Inspect)			May 13, 2023 5:01am
examples-nonmonorepo	🔄 Building (Inspect)			May 13, 2023 5:01am
examples-tailwind-web	🔄 Building (Inspect)			May 13, 2023 5:01am
examples-vite-web	🔄 Building (Inspect)			May 13, 2023 5:01am

6 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
examples-designsystem-docs	⬜️ Ignored (Inspect)			May 13, 2023 5:01am
examples-gatsby-web	⬜️ Ignored (Inspect)			May 13, 2023 5:01am
examples-kitchensink-blog	⬜️ Ignored (Inspect)			May 13, 2023 5:01am
examples-native-web	⬜️ Ignored (Inspect)			May 13, 2023 5:01am
examples-svelte-web	⬜️ Ignored (Inspect)			May 13, 2023 5:01am
turbo-site	⬜️ Ignored (Inspect)	Visit Preview		May 13, 2023 5:01am

[github-actions]

🟢 CI successful 🟢

Thanks

[gsoltis]

Not quite what I meant. You're seeing a slowdown because the channel is unbuffered: writers must wait for an available reader. While the first request is pending, no one can write to the channel. So, the goal is to read from the channel as fast as possible and not block reading on IO. Pseudocode of one way to do it:

func start() {
  firstRequestDone := make(chan interface{})
	go func() {
		pending := []*request{}
		startedFirstRequest := false
	FirstRequest:
		for {
			select {
			case <-firstRequestDone:
				for _, req := range pending {
					go doReq(req)
				}
				break FirstRequest
			case req <- requestsChannel:
				if startedFirstRequest {
					pending = append(pending, req)
				} else {
					startedFirstRequest = true
					doFirstReq(req)
				}
			}
		}
		for _, req := range requestsChannel {
			go doReq(req)
		}
	}()
}

In this case, you have a single reader that never blocks. When it gets the first request, it starts it. While the first request is in flight, it buffers subsequent requests. When the first request completes, it fires off the buffered requests and switches to reading and immediately firing off requests

[mehulkar]

I added this check to prevent a bunch of nils getting added to the pending slice, but I'm not sure why/how nil messages are being passed to this channel. My guess is it has something to do with the for loop, but I'm not sure.

[mehulkar]

@gsoltis thanks! this mostly worked. Only thing I don't understand he requests channel receives a ton of nil messages and not sure where they're coming from.

I also don't quite get the for+select combo pattern, but I see it's a common way to listen for messages, so I'll read up on that.

[mehulkar]

Going to merge this into the base PR for a holistic look and put in any questions there.