Hey guys Fast query about coder/websocket + Echo v5:
Since Echo already runs every handler in its personal goroutine, is it appropriate to simply block the handler goroutine with the learn loop instantly — no further go readPump() wanted?
“`
func (h *Handler) HandleWS(c echo.Context) error {
conn, _ := websocket.Settle for(c.Response(), c.Request(), nil)
defer conn.CloseNow()
for {
_, knowledge, err := conn.Learn(c.Request().Context())
if err != nil { return nil }
h.hub.Publish(knowledge)
}
}
“`
And since coder/websocket handles concurrent writes internally, the hub can name conn.Write() instantly and not using a separate writePump goroutine — is that the best sample?
Yeah – you shouldn’t have to fret about spawning goroutines in your handler. Every handler may have its’ personal goroutine. I feel the Gorilla go readPump() sample is predicated on the concept that they needed the handler func to return they usually needed to handle the goroutines for websockets manually. Blocking the handler func is a positive sample.
1 Like
Coming back from the handler ensures that the decision stack not holds references to knowledge eligible for rubbish assortment. A separate write pump can stop a stalled connection from blocking the writer.
