[question] Question on concurrent writer.

[linrl3]

Describe the problem you're having

A clear and concise description of what the bug is.
From godoc:Connections support one concurrent reader and one concurrent writer. Applications are responsible for ensuring that no more than one goroutine calls the write methods (NextWriter, SetWriteDeadline, WriteMessage, WriteJSON, EnableWriteCompression, SetCompressionLevel) concurrently and that no more than one goroutine calls the read methods (NextReader, SetReadDeadline, ReadMessage, ReadJSON, SetPongHandler, SetPingHandler) concurrently.

So my problem is could we use 2 or more goroutine for Write method? I used 2 goroutine without any mutex, but it looked all good.
…

Versions

Go version: go version

package version: run git rev-parse HEAD inside the repo

…

"Show me the code!"

A minimal code snippet can be useful, otherwise we're left guessing!

Hint: wrap it with backticks to format it

…

[fishyww]

Hello ~ can you provide sample code?

[ghost]

So my problem is could we use 2 or more goroutine for Write method?

No, the documentation says it's not allowed. Use a mutex or some other form of synchronization.

I used 2 goroutine without any mutex, but it looked all good.

You were lucky.

[linrl3]

So my problem is could we use 2 or more goroutine for Write method?

No, the documentation says it's not allowed. Use a mutex or some other form of synchronization.

I used 2 goroutine without any mutex, but it looked all good.

You were lucky.

Yes, I got panic eventually...

[melekes]

This can be closed imho.

[justinrush]

I get why you can't support more than one concurrent writer and don't have any real problem using a mutex, but since you specifically don't allow more than one writer, why not just have the mutex inside of the websocket struct? why force every person that uses the code to implement the mutex in their application?

[ghost]

@justinrush A mutex is not needed when a single goroutine writes to the connection. None of the examples in this repository use a mutex.

There's not a single method where the mutex should be locked/unlocked. In the following code, the lock comes before setting deadline and after closing the writer. I think it would have been better to design the API so the connection can manage the lock, but it's too late for that.

x.mu.Lock()
x.c.SetWriteDeadline(time.Now().Add(writeWait))
w, err := x.c.NextWriter(websocket.TextMessage)
if err != nil {
    return err
}
                      
...
w.Write(data)
...

err := w.Close()
x.mu.Unlock()
return err

[justinrush]

Ya, it just feels like its pretty common to have an app design where you end up needing the mutex. It makes sense that the ship has sailed on including it by default in the library as there are a bunch of projects that are already doing the locking. Thanks for following up

[ghost]

@justinrush It may be common to use a mutex, but it's a lot easier to avoid server stalls on dead or stuck clients using a goroutine. Most users of mutexes should probably be using a goroutine to ensure no more than one concurrent writer.

[IngCr3at1on]

Without attempting to read garyburd's mind I would assume the reasoning here is simple; the package is meant to implement the websocket RFC, without attempting to assume how it will be used. Put even more simply; application logic belongs in the application.

[garyburd]

@IngCr3at1on and the ghost answered all of the questions in this issue.