RESOLVED FIXED 183326
CoordinatedGraphicsScene: properly limit data specific to state commit operation 
https://bugs.webkit.org/show_bug.cgi?id=183326
Summary CoordinatedGraphicsScene: properly limit data specific to state commit operation
Zan Dobersek
Reported 2018-03-05 02:41:13 PST
CoordinatedGraphicsScene: properly limit data specific to state commit operation
Attachments
Patch (16.97 KB, patch)
2018-03-05 02:47 PST, Zan Dobersek 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Zan Dobersek
Comment 1 2018-03-05 02:47:28 PST
Created attachment 334993 [details] Patch
Sergio Villar Senin
Comment 2 2018-03-06 01:05:44 PST
Comment on attachment 334993 [details] Patch Why not using a RAII approach? CommitScope could be a class and the cleanups could be done in the destructor which would be called once the variable gets out of scope.
Zan Dobersek
Comment 3 2018-03-06 03:32:24 PST
(In reply to Sergio Villar Senin from comment #2) > Comment on attachment 334993 [details] > Patch > > Why not using a RAII approach? CommitScope could be a class and the cleanups > could be done in the destructor which would be called once the variable gets > out of scope. Structs are same as classes, just the default member accessibility is public. As such, the default destructor ivokes destructors of both containers, effectively cleaning up every object that's been stored there during the state commit op.
Zan Dobersek
Comment 4 2018-03-06 03:34:22 PST
Comment on attachment 334993 [details] Patch Clearing flags on attachment: 334993 Committed r229315: <https://trac.webkit.org/changeset/229315>
Zan Dobersek
Comment 5 2018-03-06 03:34:26 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 6 2018-03-06 03:35:31 PST
<rdar://problem/38174962>
Sergio Villar Senin
Comment 7 2018-03-06 03:42:38 PST
(In reply to Zan Dobersek from comment #3) > (In reply to Sergio Villar Senin from comment #2) > > Comment on attachment 334993 [details] > > Patch > > > > Why not using a RAII approach? CommitScope could be a class and the cleanups > > could be done in the destructor which would be called once the variable gets > > out of scope. > > Structs are same as classes, just the default member accessibility is public. > > As such, the default destructor ivokes destructors of both containers, > effectively cleaning up every object that's been stored there during the > state commit op. Not sure if you're getting my point, what I wanted is to get rid of the explicit .clear()
Zan Dobersek
Comment 8 2018-03-06 04:13:07 PST
(In reply to Sergio Villar Senin from comment #7) > (In reply to Zan Dobersek from comment #3) > > (In reply to Sergio Villar Senin from comment #2) > > > Comment on attachment 334993 [details] > > > Patch > > > > > > Why not using a RAII approach? CommitScope could be a class and the cleanups > > > could be done in the destructor which would be called once the variable gets > > > out of scope. > > > > Structs are same as classes, just the default member accessibility is public. > > > > As such, the default destructor ivokes destructors of both containers, > > effectively cleaning up every object that's been stored there during the > > state commit op. > > Not sure if you're getting my point, what I wanted is to get rid of the > explicit .clear() Right, it's not necessary for those to be explicitly called, I'll remove them.
Note You need to log in before you can comment on or make changes to this bug.