Remove buffer waiting condition

[edaniels]

Buffer's usage of waiting causes a scenario where if two reads come in while a write is happening can cause waiting to be stuck in false and all write "signals" will be dropped. After reading through the code, I can't figure out why the waiting condition is necessary; the worst thing I can imagine is we don't send to the buffered channel as often.

Fixes #299

[edaniels]

@paulwe thanks for the feedback on #304. After reading through my code, I realized removing waiting was what mattered for buffer's specific use case.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.20%. Comparing base (d55a60c) to head (7fee991).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #305      +/-   ##
==========================================
+ Coverage   83.08%   83.20%   +0.11%     
==========================================
  Files          39       39              
  Lines        2726     2721       -5     
==========================================
- Hits         2265     2264       -1     
+ Misses        335      332       -3     
+ Partials      126      125       -1     

Flag	Coverage Δ
go	83.11% <100.00%> (+0.19%)	⬆️
wasm	65.07% <100.00%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[edaniels]

Confirmed with this change it fixes #299 when running go test -run TestPeerConnection_Simulcast_Probe/Break_NonSimulcast -count=100. Without it, it fails on the first run.

[paulwe]

the goal was to reduce the overhead from writing when there is no pending read but the state gets mangled if there is more than one reader. i mistakenly assumed there was no use case for concurrent reading. it's probably possible to implement this with a counter instead of a bool but it's not critical...

[edaniels]

the goal was to reduce the overhead from writing when there is no pending read but the state gets mangled if there is more than one reader. i mistakenly assumed there was no use case for concurrent reading. it's probably possible to implement this with a counter instead of a bool but it's not critical...

I'll give the counter some short thought!