[NEW] Video conference #237
Conversation
No more experimental coroutines since it has reached a stable version!
|
|
||
| logger.debug { "running ping if active" } | ||
| logger.debug { "Running ping if active" } | ||
| if (!isActive) return@launch |
There was a problem hiding this comment.
This isn't necessary since pings are suspension functions
|
|
||
| logger.debug { "Scheduling ping timeout in $timeout milliseconds" } | ||
| timeoutJob = launch(parentJob) { | ||
| delay(timeout) | ||
| if (!isActive) return@launch |
There was a problem hiding this comment.
Not necessary since delay is a suspension function
| @@ -331,11 +303,11 @@ class Socket( | |||
|
|
|||
| private fun close() { | |||
| processingChannel?.close() | |||
There was a problem hiding this comment.
Why not just make this nonnull and declare it on creation like parent job?
If you really needed you could make the creation lazy and resettable
| launch(parent = parentJob) { | ||
| messagesChannel.send(message) | ||
| } | ||
| launch(parentJob) { messagesChannel.send(message) } |
There was a problem hiding this comment.
You really shouldn't do this if you essentially expect unlimited channel sizes. Otherwise once you have a buffer you'll just be launching a bunch of jobs to wait for the channel to fill. You should either make this suspended, or enforce an UNLIMITED capacity and use offer, which doesn't suspend. You can look up 'backpressure' for more info. This applies for every launch -> send logic.
| logger.debug { "Parent job: $parentJob" } | ||
| } | ||
| launch(parent = parentJob) { | ||
| launch { | ||
| if (processingChannel == null || processingChannel?.isFull == true || processingChannel?.isClosedForSend == true) { | ||
| logger.debug { "processing channel is in trouble... $processingChannel - full ${processingChannel?.isFull} - closedForSend ${processingChannel?.isClosedForSend}" } |
There was a problem hiding this comment.
What's the point of checking this if you are still going to send a message so long as a channel is null? Your code is going to crash if you send a value when a channel doesn't allow it
|
@AllanWang I'll make the changes here while making sure it is still a WIP PR. |
|
Coroutines improvements which need to be done (introduced on this PR) will be addressed here: #239 |
Add support for video call into the SDK. Also updates dependencies version (coroutines is no more experimental!)