[Webkit-unassigned] [Bug 62380] [EFL] correct sharedTimer value in SharedTimerEfl.cpp

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 9 15:46:29 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=62380


Lucas De Marchi <demarchi at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #96646|                            |review-, commit-queue-
               Flag|                            |




--- Comment #13 from Lucas De Marchi <demarchi at webkit.org>  2011-06-09 15:46:29 PST ---
(From update of attachment 96646)
View in context: https://bugs.webkit.org/attachment.cgi?id=96646&action=review

> Source/WebCore/ChangeLog:6
> +        SharedTimerEfl.cpp set _sharedTimer = 0 is incorrect in timerEvent, stopSharedTimer can be call by both stopSharedTimer() or by addNewTimer() withint timerFunction(). When addNewTimer(), the global _sharedTimer is replaced by the new timer object. Setting it to 0 loses the new timer object within ecore_timer without deleting it.
> +        https://bugs.webkit.org/show_bug.cgi?id=62380

Sorry, I didn't understand what you mean by "stopSharedTimer can be call by both stopSharedTimer() or by addNewTimer() withint timerFunction()".

Reading this file, what I understand is:

 * If WebCore added a new timer by calling WebCore::addNewTimer(), the old timer will be deleted by calling WebCore::stopSharedTimer(), which in turn deletes the timer inside ecore calling ecore_timer_del()

 * If the timer is triggered before WebCore calls WebCore::stopSharedTimer(), then the registered function is called and the timer is deleted inside ecore by returning ECORE_CALLBACK_CANCEL


The only reason this might be wrong (and then your patch partially right) is if the timer is supposed to keep triggering until the WebCore::stopSharedTimer() is called. In that case you have to fix the return value too, which should be EINA_TRUE.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list