Is spawning a go routine during a http.HandleFunc the right approach here?

<p>I have a small embedded webserver in an application and I want the &#34;client&#34; to be able to perform a post to it, and for the server to acknowledge the post and continue to process it. I&#39;ve done a small test showing that I can spawn a goroutine and it will continue to execute, but I am curious to know if this is a good approach. I should mention that if the async part of the operation fails, the client doesn&#39;t need to be informed. </p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>For a standalone binary it&#39;s fine, especially when it doesn&#39;t matter if the thing succeeds or not. If it matters, you should inform the client somehow. And wrap additional logic around it for retries.</p></pre>caseynashvegas: <pre><p>Thanks, great feedback.</p></pre>Incisiv3: <pre><p>It depends on the type of app and expected traffic but yeah that&#39;s fine, however one way I&#39;ve accomplished this before is to setup a pool of go-routines that wait for work (requests in this case) and are sent the data via a channel that all the workers pull from. </p> <p>The goroutine pool can either be a fixed size or auto scaling based on how many requests are sitting in the queue pending processing. That way if you get an influx of web requests you aren&#39;t overloading the server with goroutines and you&#39;re able to set a cap on the number that are spawned, and adequately adjust the size automatically to handle the back log then scale it back down once the queue is lower for a certain period of time.</p></pre>TheMerovius: <pre><p>I think, if you don&#39;t fan-out too much with goroutines, you will die for other reasons before you die because of &#34;too many goroutines&#34; (especially as, AFAIK, the http server spawns a goroutine per request anyway).</p> <p>I&#39;m baffled by the popularity of the &#34;goroutine-pool&#34; pattern. I mean, that&#39;s basically what goroutines are there to abstract <em>away</em>, they are essentially a well-working threadpool.</p></pre>caseynashvegas: <pre><p>I wasn&#39;t considering go routine pool for my use case. </p></pre>caseynashvegas: <pre><p>Thanks! </p></pre>