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
With the stabilization of async fn in trait as of 1.75, I think it would be more ergonomic to have a single state to handle all events which implements a trait rather than having to register each callback individually, and would also reduce heap allocation. Default implementations for the trait can also allow the same functionality as before, as they all return impl Future<Output = ()>.
Below is a basic example of what I'm suggesting (keep in mind I have not tested any of the code below):
structPeerConnectionInternal{/** keeping all other fields as before except removing the other event handlers **/event_handlers:Arc<ArcSwapOption<Mutex<dynPeerConnectionEventHandle>>>,}implRTCPeerConnection{/** keeping all other fns as before except removing the on_* fns **/fnwith_handler(&self,handler:implPeerConnectionEventHandle){self.internal.event_handlers.store(Some(Arc::new(Mutex::new(handler))))}}
and would change the play-from-disk-h264 example to something like:
structPeerHandler{done_tx: tokio::sync::mpsc::Sender<()>,notify_tx:Arc<Notify>,}implPeerConnectionEventHandleforPeerHandler{// Set the handler for Peer connection state// This will notify you when the peer has connected/disconnectedasyncfnon_peer_connection_state_change(&mutself,peer_connection_state:RTCPeerConnectionState){println!("Peer Connection State has changed: {peer_connection_state}");if peer_connection_state == RTCPeerConnectionState::Failed{// Wait until PeerConnection has had no network activity for 30 seconds or another failure. It may be reconnected using an ICE Restart.// Use webrtc.PeerConnectionStateDisconnected if you are interested in detecting faster timeout.// Note that the PeerConnection may come back from PeerConnectionStateDisconnected.println!("Peer Connection has gone to failed exiting");let _ = self.done_tx.try_send(());}}// Set the handler for ICE connection state// This will notify you when the peer has connected/disconnectedasyncfnon_ice_connection_state_change(&mutself,connection_state:RTCIceConnectionState){println!("Connection State has changed {connection_state}");if connection_state == RTCIceConnectionState::Connected{
notify_tx.notify_waiters();}}}#[tokio::main]asyncfnmain() -> Result<()>{/** everything above is the same **/let notify_tx = Arc::new(Notify::new());let notify_video = notify_tx.clone();let notify_audio = notify_tx.clone();let(done_tx,mut done_rx) = tokio::sync::mpsc::channel::<()>(1);let video_done_tx = done_tx.clone();let audio_done_tx = done_tx.clone();// Create a new RTCPeerConnectionlet peer_connection = Arc::new(api.new_peer_connection(config).await?.with_handler(PeerHandler{ notify_tx, done_tx }));/** everything below is the same except removing the on_* callbacks **/}
I'll follow this up with a pr, but with the scope of how much needs to be changed it might take awhile. Also, as it is a very new feature, I wanted to see if there would be any discussion.
The text was updated successfully, but these errors were encountered:
As I've been working on this, I realized that the each fn in the trait has to return impl Future<Output = ()> + Send since were dealing with multiple threads, and which cannot be represented just as an async fn. Regardless, RPITIT fns are just desugared async fns which are also supported by 1.75, the fn signature just doesn't look as clean.
With the stabilization of async fn in trait as of 1.75, I think it would be more ergonomic to have a single state to handle all events which implements a trait rather than having to register each callback individually, and would also reduce heap allocation. Default implementations for the trait can also allow the same functionality as before, as they all return
impl Future<Output = ()>
.Below is a basic example of what I'm suggesting (keep in mind I have not tested any of the code below):
changing the implementation to something like:
and would change the play-from-disk-h264 example to something like:
I'll follow this up with a pr, but with the scope of how much needs to be changed it might take awhile. Also, as it is a very new feature, I wanted to see if there would be any discussion.
The text was updated successfully, but these errors were encountered: