Threadsafety

[mappu]

I think it's currently unsafe to use a ServerConn from multiple goroutines because of a race in ServerConn.cmd between Cmd and ReadResponse.

Can this be documented?

Better yet, can it be fixed? If the control connection is protected by a mutex, do FTP servers permit you to have multiple pasv data connections open simultaneously?

[hbobenicio]

A general rule of thumb is:

"Do not communicate by sharing memory; instead, share memory by communicating."

(https://blog.golang.org/share-memory-by-communicating)

So I think that maybe the issue here is not that the ServerConn is not thread safe. The issue maybe... why you are sharing a connection between goroutines without channeling messages? And... do you really need that?

This would be my approach for multiple gouroutines needing the use of a ServerConn:

1. More naive and simple and, depending on what your trying to do, also expensive: Open one connection per goroutine. Do not share connections, but share it's processing result with channels.
2. More complex and, depending on what your trying to do, performant: Create a connection pool for your ServerConn. Create a goroutine for managing it (if the pool library used do not already provides that) in a loop which the other goroutines could send message for and demand accordingly.