Explain how filewatch and other examples ensure at most one concurrent writer

[stevenh]

While its not broken filewatch should really use WriteControl to send Ping messages.
https://github.com/gorilla/websocket/blob/master/examples/filewatch/main.go#L106

[garyburd]

Why? The concurrency of WriteControl is not needed.

[stevenh]

Best practice?

We used this as an example of how two add a pinger using websocket and it caused the issue as per: #83

[garyburd]

Best practice in this case is to use WriteMessage.

[garyburd]

I am looking for someone to help on this issue.

[hetao29]

Hi, garyburd, we are use this library for more than 1000 users chartroom program, concurrent writing is needed, 1000 users * 20 messsages per seconds, we must put this worker into goroutine, please tell me ,how to best practice.

Now I fork it and add writerlocker and readerlocker, but it's not the best way I think.

[garyburd]

@hetao29 Use a sync.Mutex in your application to ensure that only one goroutine calls the write methods concurrently or use a single goroutine for all writes as is done in the chat example.

[hetao29]

Hi, @GaryBud, In your chat example, high concurrent broadcast is problematic, a network delay of w.Write (message) (line 102, file client.go) will block all subsequent w.Write (message)

If you want to broadcast to 1000+ people at the same time:

"a single goroutine for all writes", if a person's network delay, will lead to all other people delay or block like your chat example;

"one goroutine calls the write methods concurrently", but will lead to a large number The goroutine generation, in the stress test, the memory and cpu will continue to rise.

[elithrar]

@hetao29 Are you observing that?

Note that the chat example spins up a readPump and writePump per connection and then pushes messages into each clients' send channel - https://github.com/gorilla/websocket/blob/master/examples/chat/hub.go#L45

This channel is buffered - and the loop over all clients does not block based on a receiver.

[hetao29]

@elithrar Yes, I have observing the buffered channel at client.go
&Client{hub: hub, conn: conn, send: make(chan []byte, 256)}
Theoretically more than 256, it will block, but I actually tested, this situation is still not easy to appear, thank you much!

[garyburd]

@hetao29 Because hub uses select with default when sending the channel, the hub does not block in theory or in practice.

[ghost]

The package documentation covers everything that a user of the package needs to know regarding concurrency. Is more documentation required?

[garyburd]

The file watch example, the original subject of this issue, is correct. The concurrency requirements for the package is documented in the package comment.