-
Notifications
You must be signed in to change notification settings - Fork 128
Add a Job manager #706
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.
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
base: v.next
Are you sure you want to change the base?
Add a Job manager #706
Conversation
| } | ||
| try | ||
| { | ||
| // TODO: Check app manifest for background task declaration and provide better instructions how to register the background task |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this requirement be documented in the Readme about silent failures if not configured correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I was curious if the success and failure behavior are consistent across the platforms?
| private void SaveState(string? json) | ||
| { | ||
| using var file = File.Open(GetStateFilename(), FileMode.Create, FileAccess.Write, FileShare.Write); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This SaveState implementation is still crash‑unsafe and concurrency‑unsafe.
- This truncates the file immediately and then writes the new content. LoadStateInternal has a chance to observe a half-written file.
- If the process/thread dies mid-write, we end up with an empty or partially-written file.
- With two possible writers (foreground or background), using FileShare.Write makes corruption more likely. Both file-opens will succeed but writes will be interleaved.
You can fix some of these issues by writing to a temp file and then doing an atomic replacement (File.Move for initial write, File.Replace for overwrites). The writers are still racing each other, but at least the file on disk will always be intact.
If you want to eliminate writer races, you can do some cross-process synchronization -- either a named mutex or a .lock file with FileShare.None.
A port of the Swift toolkit JobManager. See: https://github.com/Esri/arcgis-maps-sdk-swift-toolkit/blob/117a0a35662f7a2403b22d7048e4f0c53a97c07c/Sources/ArcGISToolkit/Components/JobManager/JobManager.swift