On Mon, 6 Mar 2017 04:31:50 -0800 (PST) Nick Rio <nickri...@gmail.com> wrote:
[...] > I really hope they can add that (IO Notify Poll?) into Golang so I > can implement my server in other models instead of > One-Connection-One-Goroutine one. The real problem with I/O notifications -- as you want them to work -- is that they defeat the main feature of Go which it has to do with concurrency: its model allows you to use *sequential* code to deal with networked streams of data -- instead of callback hell found with other approaches. And a subtle feature of Go which actually makes this possible is that via goroutines, it supports several independent call stacks which can be switched on the fly. As soon as you return to a classic poll mode, you reinvent event-driven network programming with all its typical strings attached: explicit management of the state of parsing of the incoming data stream for each connection, and the related buffer management. (This stuff is very well explained in the classic [1].) Hence "one goroutine per one client's data stream" model is here for a reason. I concur that it indeed might be suboptimal even with newer Go runtimes which IIUC initially allocate quite a modest amount of stack space for a fresh goroutine. In such case, a hybrid model of having a specialized goroutine (or a set of them) to handle idling connections might indeed be a way to go as it would serve merely as a watchdog and not deal with actual data processing. 1. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
