4 ms·

> But instead, I have to spawn two more goroutines, one to "monitor" (really, read) from inbound, and one for outbound. What does Golang's select/case not do t

by smegel 14y ago

> But instead, I have to spawn two more goroutines, one to "monitor" (really, read) from inbound, and one for outbound. What does Golang's select/case not do that you want?

tptacek 14y ago
Is there some feature of the language or the libraries that I am missing that turns a socket (err, a TCPConn) into a channel that I can read with Golang's select construction? Seriously asking. That would be awesome.
- smegel 14y ago
  No, I think you would need to wrap the TCPConn in a goroutine that does the Read, handles any errors, then passes the bytes back to the consumer via a channel. At least it would be a very generic and small goroutine to do this. I agree that would be a nice feature though.
  - tptacek 14y ago
    You know what's happening in this thread? I made it sound like I was criticizing Go for needing to spawn goroutines to do this. I'm not! It makes sense, in the context of Go, to do it this way, even though as a C programmer by training that's not my first thought on how to do it. I'm not criticizing Go for being anti-event; I'm just observing that it is. Idiomatic Go --- like, the code in the standard library --- has a strong bias towards straight-line code.
    - smegel 14y ago
      > I'm not criticizing Go for being anti-event; I'm just observing that it is. Idiomatic Go --- like, the code in the standard library --- has a strong bias towards straight-line code. I think I understand where you are coming from now - I think you are saying Go is "anti-event-based-callback-driven" rather than "anti-event-loop-implementation" - which is absolutely true. Go's concurrency model is build on CSP (Hoare's Communicating Sequential Processes)[1] which seems to advocate procedural threads rather than callbacks. [1] http://golang.org/doc/go_faq.html#goroutines http://golang.org/doc/go_faq.html#goroutines

4 ms·

> But instead, I have to spawn two more goroutines, one to "monitor" (really, read) from inbound, and one for outbound. What does Golang's select/case not do t

by smegel 14y ago

> But instead, I have to spawn two more goroutines, one to "monitor" (really, read) from inbound, and one for outbound. What does Golang's select/case not do that you want?

tptacek 14y ago
Is there some feature of the language or the libraries that I am missing that turns a socket (err, a TCPConn) into a channel that I can read with Golang's select construction? Seriously asking. That would be awesome.
- smegel 14y ago
  No, I think you would need to wrap the TCPConn in a goroutine that does the Read, handles any errors, then passes the bytes back to the consumer via a channel. At least it would be a very generic and small goroutine to do this. I agree that would be a nice feature though.
  - tptacek 14y ago
    You know what's happening in this thread? I made it sound like I was criticizing Go for needing to spawn goroutines to do this. I'm not! It makes sense, in the context of Go, to do it this way, even though as a C programmer by training that's not my first thought on how to do it. I'm not criticizing Go for being anti-event; I'm just observing that it is. Idiomatic Go --- like, the code in the standard library --- has a strong bias towards straight-line code.
    - smegel 14y ago
      > I'm not criticizing Go for being anti-event; I'm just observing that it is. Idiomatic Go --- like, the code in the standard library --- has a strong bias towards straight-line code. I think I understand where you are coming from now - I think you are saying Go is "anti-event-based-callback-driven" rather than "anti-event-loop-implementation" - which is absolutely true. Go's concurrency model is build on CSP (Hoare's Communicating Sequential Processes)[1] which seems to advocate procedural threads rather than callbacks. [1] http://golang.org/doc/go_faq.html#goroutines http://golang.org/doc/go_faq.html#goroutines