Skip to content

Fix data-channels-flow-control example #846

@hugoArregui

Description

@hugoArregui

There is a problem with the current example, the peer may stop sending data here if the max buffer size has not been reached before this point and since the callback is executed as part of the stream processing thread, that will block everything.

So we need to:

  1. Find a better flow control mechanism for the example
  2. Decide if we should execute the callback in another goroutine so we ensure we don't block the stream, or, document the fact that users should make sure their code don't block.

As a suggestion for (1) I wrote this code: https://github.com/pion/webrtc/blob/topic-test-dc-perf/examples/data-channels-flow-control/main.go#L31 which uses a queue and drains it whenever it's possible. It might not the most efficient way having a channel in the middle of the write operation but I like how easy is to reason about it. I think it makes sense for an example.

Regarding (2) I think we should probably execute the callback in another goroutine since that's consistent with do things in other places, but I have no strong opinion on this matter.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions