Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Initial websocket support #57
Handles issue #54
Can be tested here http://www.websocket.org/echo.html. Just put in
Not sure how much logging there should be, but logs websocket connect/disconnect and error states.
Added godep for gorilla/websocket
Heh, probably not the right solution. As I understand it, at some point in the future, it is intended that the go scheduler automatically scale beyond a single core, making
Can we push the list management into a single goroutine, and have the http handler register / remove connections by passing a message over a channel to the list manger? If possible, that would make things thread safe.
I think a channel backed solution may be overkill here.
This seems to fit the RWMutex use case where we need blanket access to the list of ws clients by a number of go routines most of which just doing reads. (and in all fairness, a channel is implemented with a set of mutexs anyways...). This way we have good read performance 99% of the time (which is the main concern here).
Golang blog - (see section on concurrency where they suggest using RWMutex) http://blog.golang.org/go-maps-in-action
RWMutex - http://golang.org/pkg/sync/#RWMutex
Anyways, I'll see what I can throw together to mitigate that problem.
Sent from my iPhone