You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we use buffered channels with quite a larger buffer when we're sending messages from the peer to the conference to mutate the state of a conference. We do the same when we send incoming To-Device messages to the conference.
These queues don't seem to be very useful in most cases. It seems it's OK to let the senders block if the conference can't keep up with the messages as it would introduce a natural backpressure mechanism (i.e. it does not make sense to fill up the queue with the messages that must not even be necessary). It seems to play better with an idiomatic Go.
The text was updated successfully, but these errors were encountered:
daniel-abramov
changed the title
Introduce a backpressure when sending the messages to the conference
Introduce a backpressure when sending peer messages to the conference
Feb 15, 2023
Currently, we use buffered channels with quite a larger buffer when we're sending messages from the peer to the conference to mutate the state of a conference. We do the same when we send incoming To-Device messages to the conference.
These queues don't seem to be very useful in most cases. It seems it's OK to let the senders block if the conference can't keep up with the messages as it would introduce a natural backpressure mechanism (i.e. it does not make sense to fill up the queue with the messages that must not even be necessary). It seems to play better with an idiomatic Go.
The text was updated successfully, but these errors were encountered: