summaryrefslogtreecommitdiff
path: root/core/fpdfapi/fpdf_render
diff options
context:
space:
mode:
authortsepez <tsepez@chromium.org>2016-08-05 17:12:27 -0700
committerCommit bot <commit-bot@chromium.org>2016-08-05 17:12:27 -0700
commit8ca63de14d522d3d259d74fa43b28b05b02728e8 (patch)
treedd86d4b10e658cef8bf5fea5d99baa1d15bda7ca /core/fpdfapi/fpdf_render
parent135b99861d0d898850754a845f607ec48f0bcccc (diff)
downloadpdfium-8ca63de14d522d3d259d74fa43b28b05b02728e8.tar.xz
Remove another potential stale CJS_Timer usage
Fix memory ownership model for PDFium timers. The |app| class owns the CJS_Timer as part of its vector<unique_ptr> to them. The CJS_Timer "owns" its slot in the global ID to timer map, and removes itself when it is destroyed. Nothing else deletes from the global map. Deleting from the global map is accompanied by a callback to the embedder to clear its resources. Next, the proper way to remove a CJS_Timer is by going through the app, and having the app erase its unique ptr, which then deletes the CJS_Timer, which in turn cleans up the global map. Provide a CJS_Timer::Cancel static method to do this conveniently. There is a alternate path to the CJS_timer via JS and its CJS_TimerObj. CJS_TimerObj owns a TimerObj that currently points to the CJS_Timer. If the timer fires, and cleans itself up, this can go stale. Make the TimerObj maintain a weak reference via global timer ID rather than a direct pointer to the CJS_Timer, so that if the timer fires and is destroyed, future attempts to cancel find nothing. There is another path, where if the JS timer object is GC'd, then we just clean up its CJS_TimerObj without touching the actual CJS_Timers. We could make this match the spec by calling into the new cancel routine as described above, but it seems weird to have a timer depend on whether a gc happened or not. A subsequent CL will rename these objects to more closely match the conventions used by the other JS wrappers. BUG=634716 Review-Url: https://codereview.chromium.org/2221513002
Diffstat (limited to 'core/fpdfapi/fpdf_render')
0 files changed, 0 insertions, 0 deletions