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(engine-dylib): do not keep temp file and delete it automatically #2547

Merged
merged 4 commits into from
Sep 1, 2021
Merged

fix(engine-dylib): do not keep temp file and delete it automatically #2547

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
297d9c1
fix(engine-dylib): do not keep temp file and delete it automatically …
bnjjj Aug 31, 2021
efc84e1
fix(engine-dylib): do not delete temp file in every scenarios
bnjjj Sep 1, 2021
8d8ee21
fix(engine-dylib): display error log if we can't delete the tmp file
bnjjj Sep 1, 2021
a0dbc99
fix(engine-dylib): add log feature for tracing in engine-dylib
bnjjj Sep 1, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions lib/engine-dylib/src/artifact.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,12 @@ pub struct DylibArtifact {
frame_info_registration: Mutex<Option<GlobalFrameInfoRegistration>>,
}

impl Drop for DylibArtifact {
fn drop(&mut self) {
std::fs::remove_file(&self.dylib_path).expect("cannot delete the temporary artifact");
Copy link
Member

Choose a reason for hiding this comment

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

This will drop the file always, however there is only one scenario where we should do it.

deserialize (which creates a temporal file and then callsdeserialize_from_file_unchecked) should delete the temporal file, however deserialize_from_file (which doesn't create a temporal file) should not delete the file (since it was provided by the user), we can provably have a new field specifying if the file is temporal or not and delete it on such case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok got it thank you, btw what's your policies regarding to error in this case ? Do you prefer to panic as I do here or just display a log ?

Copy link
Member

Choose a reason for hiding this comment

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

I think it might be better to gracefully dismiss the error in case the worst case scenario is reached, so logging seems like a better option than a panic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's what I think too. Updated, thanks :)

Copy link
Member

Choose a reason for hiding this comment

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

That's great, will review now!

}
}

fn to_compile_error(err: impl Error) -> CompileError {
CompileError::Codegen(err.to_string())
}
Expand Down Expand Up @@ -231,7 +237,7 @@ impl DylibArtifact {

// Re-open it.
let (mut file, filepath) = file.keep().map_err(to_compile_error)?;
file.write(&obj_bytes).map_err(to_compile_error)?;
file.write_all(&obj_bytes).map_err(to_compile_error)?;
filepath
}
None => {
Expand Down Expand Up @@ -261,7 +267,7 @@ impl DylibArtifact {
let (mut file, filepath) = file.keep().map_err(to_compile_error)?;
let obj_bytes = obj.write().map_err(to_compile_error)?;

file.write(&obj_bytes).map_err(to_compile_error)?;
file.write_all(&obj_bytes).map_err(to_compile_error)?;
filepath
}
};
Expand Down