Is there a need for goroutine for a UDP server?

<p>I&#39;m not sure if the question makes sense but since there is not state in UDP, for a server just listening for incoming data w/o writing a for loop should be enough right?</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>It might make sense, to decouple the receiving/parsing of packages from the processing. For example, if you have a bittorrent client that needs to receive a package and write a chunk to disk - it might turn out, that a simple receive-write-loop is not very performant in this case, as you need to write for a disk-write to succeed before reading another package and the other way around. Decoupling that into separate goroutines might make sense.</p> <p>I don&#39;t think it depends very much on UDP/TCP whether concurrency is appropriate, but mostly on what you are trying to do with the data. If it&#39;s a problem that can well be abstracted into separate concurrent processes, you should probably still do it :)</p></pre>kunos: <pre><p>If the server really doesn&#39;t do anything other than waiting for a packet then yes. In Go sockets cannot be made non blocking, that&#39;s why most people use a go routine and channel to receive.</p></pre>brentrowland: <pre><p>For something simple, like a message multiplexor (think chat server), a single thread is quite often more than enough. There is a certain amount of queuing in your network stack that is more than adequate when each packet is self-contained and handled quickly. However, should your processing involve blocking operations, such as writing to a disk with unpredictable latency (think Amazon EBS or an external USB drive that may need to spin up) or calling out to web service, then some kind of concurrency is warranted.</p></pre>