Skip to content

Conversation

@christothes
Copy link
Collaborator

@christothes christothes commented Jun 23, 2025

closes #474

{
ArrayPool<byte>.Shared.Return(_receiveBuffer);
_webSocket?.Dispose();
if (!_disposed)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not thread safe.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but do we expect a given instance of the enumerator to be run concurrently?

Copy link
Collaborator

@KrzysztofCwalina KrzysztofCwalina Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably not in real scenarios, but double return to a pool is such a severe bug. I think we should not be using the pool unless we can guarantee 100% correctness, even in contrived or bug cases or when the user has a bug in their code. Double returns to the pool mess up the whole app domain and can lead issues like data loss.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't hurt to use an Interlocked, e.g.

if (Interlocked.Exchange(ref _receiveBuffer, null) is byte[] toReturn)
{
    ArrayPool<byte>.Shared.Return(toReturn);
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephentoub, do we need to make the filed volatile so that there is no use after free?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making it volatile won't really help if there's (erroneous) concurrent use of other members of the enumerator, as regardless of whether it's volatile or not they could have already grabbed a snapshot of the field's value. And non-concurrent use doesn't need a fence. Interlocked.Exchange itself is also a full fence.

Copy link
Collaborator

@KrzysztofCwalina KrzysztofCwalina Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true

Copy link
Contributor

@stephentoub stephentoub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@KrzysztofCwalina KrzysztofCwalina merged commit c57f430 into openai:main Jun 24, 2025
1 check passed
jsquire pushed a commit to jsquire/openai-dotnet that referenced this pull request Jul 10, 2025
…event multiple disposals (openai#476)

* Improve disposal logic in AsyncWebsocketMessageResultEnumerator to prevent multiple disposals

* fb

* Update src/Custom/RealtimeConversation/Internal/AsyncWebsocketMessageEnumerator.cs

Co-authored-by: Stephen Toub <[email protected]>

---------

Co-authored-by: Stephen Toub <[email protected]>
jsquire added a commit that referenced this pull request Jul 10, 2025
…event multiple disposals (#527)

* Improve disposal logic in AsyncWebsocketMessageResultEnumerator to prevent multiple disposals (#476)

* Improve disposal logic in AsyncWebsocketMessageResultEnumerator to prevent multiple disposals

* fb

* Update src/Custom/RealtimeConversation/Internal/AsyncWebsocketMessageEnumerator.cs

Co-authored-by: Stephen Toub <[email protected]>

---------

Co-authored-by: Stephen Toub <[email protected]>

* Update src/Custom/Realtime/Internal/AsyncWebsocketMessageEnumerator.cs

---------

Co-authored-by: Christopher Scott <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>
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.

Evaluate ArrayPool usage in AsyncWebsocketMessageEnumerator

5 participants