RESOLVED INVALID 114652
Verify that r148475 didn't break the HeapTimer implementation for Qt 
https://bugs.webkit.org/show_bug.cgi?id=114652
Summary Verify that r148475 didn't break the HeapTimer implementation for Qt
Mark Hahnenberg
Reported 2013-04-15 17:57:41 PDT
http://trac.webkit.org/changeset/148475 changed the way which HeapTimers are destroyed. I modified the Qt code in a way that seemed sensible so that it would build, but I'm not 100% confident in my change since I'm unfamiliar with Qt's platform-specific timer/event loop implementations.
Attachments
Add attachment proposed patch, testcase, etc.
Allan Sandfeld Jensen
Comment 1 2013-04-16 03:05:49 PDT
Thanks for warning. The important thing here is that the HeapTimer is destroyed by the owning thread/event loop. In Qt this is usually the thread where the object was created, but the HeapTimer is constantly migrated to the thread that holds the JS APILock. So as long as that is help when the delete happens, it should be fine. If that doesn't happen. Things get more complicated. It should then be deleted using deleteLater() (to the let its own eventloop delete it), and would need some race-condition protection in the fire-handler similar to what you have for CF.
Sam Sneddon [:gsnedders]
Comment 2 2022-07-30 13:33:37 PDT
The Qt port has been removed from WebKit; -> INVALID.
Note You need to log in before you can comment on or make changes to this bug.