Page MenuHomePhabricator

efl/timer: correctly handle recursion for timer processing
ClosedPublic

Authored by zmike on Oct 25 2019, 7:20 AM.

Details

Summary

if the currently-processed timer is recursively deleted (efl_del) while
it is inside the timer tick event callback, we must correctly handle this
case:

  • in the place where a timer's inlist is de-linked, we must check to see if the timer is the current timer and then update that pointer with the next timer in the list
  • in the post-tick part of timer processing, we must NOT update the current timer pointer if we detect that it has been updated recursively

this fixes processing of timers in the mainloop to trigger more than one legacy timer
per mainloop iteration and likely has some (positive) impact on mainloop throughput

@fix
Depends on D10514

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
zmike created this revision.Oct 25 2019, 7:20 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

zmike requested review of this revision.Oct 25 2019, 7:20 AM
cedric accepted this revision.Oct 25 2019, 10:48 AM
This revision is now accepted and ready to land.Oct 25 2019, 10:48 AM
Closed by commit rEFLdcc7467c0031: efl/timer: correctly handle recursion for timer processing (authored by zmike, committed by Marcel Hollerbach <mail@marcel-hollerbach.de>). · Explain WhyOct 29 2019, 8:12 AM
This revision was automatically updated to reflect the committed changes.