Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upMake sure that we send NewChannel before any other event #364
Conversation
| @@ -76,6 +76,7 @@ pub struct GStreamerWebRtcController { | |||
| remote_offer_generation: u32, | |||
| _main_loop: glib::MainLoop, | |||
| data_channels: Arc<Mutex<HashMap<DataChannelId, GStreamerWebRtcDataChannel>>>, | |||
| data_channels_event_queue: Arc<Mutex<HashMap<DataChannelId, Vec<DataChannelEvent>>>>, | |||
This comment has been minimized.
This comment has been minimized.
| data_channels: Arc<Mutex<HashMap<DataChannelId, GStreamerWebRtcDataChannel>>>, | ||
| data_channels_event_queue: Arc<Mutex<HashMap<DataChannelId, Vec<DataChannelEvent>>>>, |
This comment has been minimized.
This comment has been minimized.
jdm
Jun 25, 2020
Member
I get a little bit nervous about races when there are multiple independent locks for what is essentially the same data. Is there any way to do something like:
enum DataChannelState {
Buffered(Vec<DataChannelEvent>),
Created(GStreamerWebRtcDataChannel),
}And then only have a single hashmap?
This comment has been minimized.
This comment has been minimized.
Manishearth
Jun 25, 2020
Member
I think we can have a single hashmap adn then just a Sender/Receiver pair, the vec is being used as a queue.
But the enum works too
| match channel { | ||
| DataChannelEventTarget::Buffered(ref mut events) => { | ||
| for event in events.drain(0..) { | ||
| thread_.internal_event( |
This comment has been minimized.
This comment has been minimized.
jdm
Jun 26, 2020
Member
Is there any chance that we could have a buffered close event? If so, we will end up registering a channel after the close.
|
r=me when you're satisfied with the answer to my question. |
|
@bors-servo r=jdm |
|
|
Make sure that we send NewChannel before any other event
|
|
|
This was merged already 6aa53e1 |
ferjm commentedJun 24, 2020
No description provided.