Commit 423a02a
committed
Fix leak linked to event listeners on quality change
The #1778 and #1779 issues / PR noticed a leak that seem to arise when
multiple quality switches happen.
I'm still unsure of the severity (looking at it what this fixes seems
very minimal, and we did not notice this yet on production at Canal+
including on low-memory devices for what seems to be a change that has
been here for 2 years - but external contributors actually did notice a
leak so maybe a set of conditions amplify the issue), but looking closely
at the code in question, there does seem to be an improper event listener
clean-up on a quality switch.
The issue is rooted in the complexity behind how quality switch happen:
- depending on heuristics, we may either perform an "urgent" quality
switch (where we directly cancel the requests linked to the older
quality) or a non-urgent one (where we will wait for the current
requests to finish and only after load the new quality).
- If non-urgent, we want to still do the requests for the new quality as
soon as we can, thus we parallelize it with the pushing operations of
the segments we just loaded from the previous quality.
Thus when a "non-urgent" quality switch happen, there might be a short
time where several quality-linked modules are running at the same time
(the old one to push segments, the new one to load them), whereas at
first glance they seemed conflicting (one loads and push one quality,
the other loads and push another quality of the same thing).
This lead to an awkward architecture where the clean-up process of those
modules is subtly different than in other RxPlayer modules - this one
has actually 2 means to terminate:
- its `terminate` parameter, kind of like a SIGTERM: just finish what
you're doing (e.g. finish loading segments and/or pushing them then
stop).
Once the `RepresentationStream` (the module in question) has finished
loading segments, it sends a `terminating` event - but it might still
be pushing segments.
It however has no event to indicate that segments have been pushed,
for now.
- its `cancelSignal` parameter, more akin to a SIGKILL: terminate
everything now without delay.
This one is e.g. triggered when stopping the content, changing the
track etc.
The leaking event listener was wrongly linked to that "SIGKILL" signal,
even if it was intended to be cleaned up when the module is not needed
anymore. When the module was only "SIGTERMed", it was not cleaned up.
---
I chose to clean it up not right when "SIGTERMed", but when the module
itself anounced that it is "terminating" (it is done loading and is now
pushing segments).
I found it to be more appropriate for the logic in question and a
corresponding `CancellationSignal` was already used for other similar
logic linked to the same lifetime.1 parent 00f9b0c commit 423a02a
1 file changed
Lines changed: 42 additions & 21 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
215 | 215 | | |
216 | 216 | | |
217 | 217 | | |
218 | | - | |
219 | | - | |
| 218 | + | |
| 219 | + | |
220 | 220 | | |
221 | 221 | | |
222 | 222 | | |
223 | | - | |
| 223 | + | |
224 | 224 | | |
225 | 225 | | |
226 | 226 | | |
| |||
243 | 243 | | |
244 | 244 | | |
245 | 245 | | |
246 | | - | |
| 246 | + | |
247 | 247 | | |
248 | 248 | | |
249 | 249 | | |
| |||
255 | 255 | | |
256 | 256 | | |
257 | 257 | | |
258 | | - | |
| 258 | + | |
259 | 259 | | |
260 | 260 | | |
261 | 261 | | |
262 | 262 | | |
263 | 263 | | |
264 | 264 | | |
265 | 265 | | |
266 | | - | |
| 266 | + | |
267 | 267 | | |
268 | 268 | | |
269 | 269 | | |
270 | 270 | | |
271 | 271 | | |
272 | | - | |
| 272 | + | |
273 | 273 | | |
274 | 274 | | |
275 | 275 | | |
| |||
278 | 278 | | |
279 | 279 | | |
280 | 280 | | |
281 | | - | |
| 281 | + | |
282 | 282 | | |
283 | 283 | | |
284 | 284 | | |
| |||
410 | 410 | | |
411 | 411 | | |
412 | 412 | | |
413 | | - | |
414 | | - | |
| 413 | + | |
| 414 | + | |
415 | 415 | | |
416 | 416 | | |
417 | 417 | | |
418 | 418 | | |
419 | 419 | | |
420 | | - | |
| 420 | + | |
421 | 421 | | |
422 | 422 | | |
423 | 423 | | |
424 | 424 | | |
425 | | - | |
426 | | - | |
| 425 | + | |
| 426 | + | |
| 427 | + | |
| 428 | + | |
| 429 | + | |
| 430 | + | |
| 431 | + | |
| 432 | + | |
| 433 | + | |
| 434 | + | |
| 435 | + | |
| 436 | + | |
| 437 | + | |
427 | 438 | | |
428 | | - | |
| 439 | + | |
429 | 440 | | |
430 | 441 | | |
431 | 442 | | |
432 | 443 | | |
433 | 444 | | |
434 | 445 | | |
435 | 446 | | |
436 | | - | |
| 447 | + | |
437 | 448 | | |
438 | 449 | | |
439 | 450 | | |
| |||
480 | 491 | | |
481 | 492 | | |
482 | 493 | | |
483 | | - | |
| 494 | + | |
| 495 | + | |
484 | 496 | | |
485 | 497 | | |
486 | 498 | | |
487 | 499 | | |
488 | 500 | | |
489 | | - | |
| 501 | + | |
490 | 502 | | |
491 | 503 | | |
492 | 504 | | |
493 | 505 | | |
494 | 506 | | |
495 | 507 | | |
496 | | - | |
| 508 | + | |
497 | 509 | | |
498 | 510 | | |
499 | 511 | | |
| |||
512 | 524 | | |
513 | 525 | | |
514 | 526 | | |
515 | | - | |
| 527 | + | |
| 528 | + | |
| 529 | + | |
| 530 | + | |
| 531 | + | |
| 532 | + | |
| 533 | + | |
| 534 | + | |
| 535 | + | |
| 536 | + | |
516 | 537 | | |
517 | 538 | | |
518 | 539 | | |
| |||
525 | 546 | | |
526 | 547 | | |
527 | 548 | | |
528 | | - | |
| 549 | + | |
529 | 550 | | |
530 | 551 | | |
531 | 552 | | |
| |||
543 | 564 | | |
544 | 565 | | |
545 | 566 | | |
546 | | - | |
| 567 | + | |
547 | 568 | | |
548 | 569 | | |
549 | 570 | | |
| |||
0 commit comments