Skip to content

Clarify concurrent use semantics for streaming types#911

Open
emcfarlane wants to merge 2 commits intomainfrom
ed/docConcurrency
Open

Clarify concurrent use semantics for streaming types#911
emcfarlane wants to merge 2 commits intomainfrom
ed/docConcurrency

Conversation

@emcfarlane
Copy link
Contributor

The docs for StreamingHandlerConn incorrectly stated that implementations "do not need to be safe for concurrent use", and the StreamingClientConn method group comments used the ambiguous phrase "may race with each other".

Replace both with consistent, precise language across all streaming interfaces and high-level stream types: the read side and write side may be used concurrently with each other, but neither side is safe to call concurrently with itself.

Fixes #871, fixes connectrpc/otelconnect-go#194

Signed-off-by: Edward McFarlane <emcfarlane@buf.build>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race Condition in otelconnect v0.7.2 with Streaming Endpoints [Documentation] Make it clearer that Send/Receive are susceptible to race conditions

1 participant