Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix FileAPI's refcount implementation #12579

Merged
merged 1 commit into from Aug 2, 2016
Merged

Fix FileAPI's refcount implementation #12579

merged 1 commit into from Aug 2, 2016

Conversation

izgzhen
Copy link
Contributor

@izgzhen izgzhen commented Jul 24, 2016 •
edited

Revise several intricate parts of FileAPI's internal refcounting-related implementation.

Goal: Get it done right once and for all.

r? @Manishearth

  • ./mach build -d does not report any errors
  • ./mach test-tidy does not report any errors
  • These changes do not require tests because it is internal logic change

This change is Reviewable

@highfive
Copy link

Heads up! This PR modifies the following files:

  • @KiChjang: components/net/filemanager_thread.rs, components/script/dom/blob.rs, components/net_traits/filemanager_thread.rs, components/net_traits/filemanager_thread.rs

@highfive
Copy link

warning Warning warning

  • These commits modify net and script code, but no tests are modified. Please consider adding a test!

@highfive highfive added the S-awaiting-review There is new code that needs to be reviewed. label Jul 24, 2016
@izgzhen
Copy link
Contributor Author

izgzhen commented Jul 24, 2016

These changes are based on https://github.com/izgzhen/gsoc-file-support/blob/master/notes/analysis.md, which is unfortunately a mess now (in continued revision...).

Basically, the fixes aim at a correct slicing: After slicing, whatever happens to parent blob should be irrelevant for child blob. I will try to comment on each vital change as well.

Also, wondering how to test that logic :/

Finally, our current design is a monster, maybe the most complicated thing I ever wrote. Hope this time it is done right.

izgzhen
izgzhen reviewed Jul 24, 2016
View reviewed changes
components/net/filemanager_thread.rs
@@ -178,7 +178,7 @@ impl<UI: 'static + UIProvider> FileManager<UI> {
if let Ok(id) = Uuid::parse_str(&id.0) {
spawn_named("revoke blob url".to_owned(), move || {
// Since it is revocation, unset_url_validity is true
let _ = sender.send(store.dec_ref(&id, &origin, true));
let _ = sender.send(store.set_blob_url_validity(false, &id, &origin));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that as long as Blob is not dropped or closed, it holds a readable reference to resource by FileID. Thus, revocation should not dec_ref but just simply flip the validity bit.

@izgzhen
Copy link
Contributor Author

izgzhen commented Jul 24, 2016

I personally think that reading through the new implementation (blob.rs, net/filemanager_thread.rs) would be easier than comparing the diff

Manishearth
Manishearth reviewed Jul 25, 2016
View reviewed changes
components/net/filemanager_thread.rs
self.remove(id);

if let Some(parent_id) = opt_parent_id {
// unset_url_validity for parent is false since we only need
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this comment isn't necessary now?

@Manishearth
Copy link
Member

Overall looks good.

While we're at it, should we add a decref in the Blob destructor (specifically, the script-side BlobImpl destructor)?

@izgzhen
Copy link
Contributor Author

izgzhen commented Jul 25, 2016 •
edited

Here we called self.clean_up_file_resource, which did the dec_ref here.

well .. but maybe this name is a bit misleading?

@Manishearth
Copy link
Member

Ah, right, we did. Sgtm.

@izgzhen
Copy link
Contributor Author

izgzhen commented Aug 1, 2016

ping?

@Manishearth
Copy link
Member

@bors-servo r+

@bors-servo
Copy link
Contributor

📌 Commit 49ed453 has been approved by Manishearth

@highfive highfive added S-awaiting-merge The PR is in the process of compiling and running tests on the automated CI. and removed S-awaiting-review There is new code that needs to be reviewed. labels Aug 2, 2016
@bors-servo
Copy link
Contributor

⌛ Testing commit 49ed453 with merge 93b130f...

bors-servo pushed a commit that referenced this pull request Aug 2, 2016
Auto merge of #12579 - izgzhen:fix-fileapi-ref, r=Manishearth
93b130f 
Fix FileAPI's refcount implementation

Revise several intricate parts of FileAPI's internal refcounting-related implementation.

Goal: Get it done right once and for all.

r? @Manishearth

<!-- Please describe your changes on the following line: -->

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it is internal logic change

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/12579)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

☀️ Test successful - arm32, arm64, linux-dev, linux-rel, mac-dev-unit, mac-rel-css, mac-rel-wpt, windows-dev

@bors-servo bors-servo merged commit 49ed453 into servo:master Aug 2, 2016
@highfive highfive removed the S-awaiting-merge The PR is in the process of compiling and running tests on the automated CI. label Aug 2, 2016
@bors-servo bors-servo mentioned this pull request Aug 2, 2016
Merged
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@Manishearth Manishearth

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@izgzhen @highfive @Manishearth @bors-servo