Bug 114652
| Summary: | Verify that r148475 didn't break the HeapTimer implementation for Qt | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mark Hahnenberg <mhahnenberg> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | allan.jensen, hausmann, mhahnenberg |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Mark Hahnenberg
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
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]
The Qt port has been removed from WebKit; -> INVALID.