Describe the issue or suggestion
ManagedWebSocket has some useful comments on thread safety above the class, in the code.
The first ("It's acceptable to call ReceiveAsync and SendAsync in parallel. One of each may run concurrently.") is well-covered on Microsoft Learn.
The second ("It's acceptable to have a pending ReceiveAsync while CloseOutputAsync or CloseAsync is called.") is useful information that I do not see on Microsoft Learn. It would be useful on CloseAsync and CloseOutputAsync (it is safe to call close methods with ReceiveAsync pending, but perhaps noting the socket will transition to aborted if other operations e.g. SendAsync, are pending). It would also be relevant on ReceiveAsync.
The third ("Attempting to invoke any other operations in parallel may corrupt the instance.") is also not documented. This could be on WebSocket itself. For example, this implies that calling CloseAsync with a SendAsync pending may corrupt the instance.
I understand that these remarks are for ManagedWebSocket, not WebSocket itself. Therefore, someone on the WebSocket team will need to assess whether these guarantees are intended to apply to all implementations of the abstract WebSocket class.
If so, this is valuable information.
Describe the issue or suggestion
ManagedWebSocket has some useful comments on thread safety above the class, in the code.
The first ("It's acceptable to call ReceiveAsync and SendAsync in parallel. One of each may run concurrently.") is well-covered on Microsoft Learn.
The second ("It's acceptable to have a pending ReceiveAsync while CloseOutputAsync or CloseAsync is called.") is useful information that I do not see on Microsoft Learn. It would be useful on CloseAsync and CloseOutputAsync (it is safe to call close methods with ReceiveAsync pending, but perhaps noting the socket will transition to aborted if other operations e.g. SendAsync, are pending). It would also be relevant on ReceiveAsync.
The third ("Attempting to invoke any other operations in parallel may corrupt the instance.") is also not documented. This could be on WebSocket itself. For example, this implies that calling CloseAsync with a SendAsync pending may corrupt the instance.
I understand that these remarks are for ManagedWebSocket, not WebSocket itself. Therefore, someone on the WebSocket team will need to assess whether these guarantees are intended to apply to all implementations of the abstract WebSocket class.
If so, this is valuable information.