-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(file-system): run asynchronous methods on seperate thread #7514
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
Conversation
All existing asyncronouse methods is `file-system` are dispatched to this Worker.
Components for the `file system` Worker.
Import the FSWorker object from components.
All existing asyncronouse methods is `file-system` are dispatched to this Worker.
Components for the `file system` Worker.
Import the FSWorker object from components.
…into file-system-thread
FSJobs interface is only worker and not needed to be exported. removed from FSWorker namespace and renamed to WorkerJobs (for semantics).
|
I don't think it is appropriate to run such a thing in a worker, considering there have been problems with workers and webpack. Much better to add native async methods and then call those from the core modules. |
|
Adding to @PeterStaev's comment, you can't spawn workers from workers, so this implementation prevents the filesystem module from being used inside a worker, and you can only access one file at a time. |
|
@mudlabs Thank you for this PR! For this specific feature we preferred a different solution that relies on native async methods #7671 as discussed above by @PeterStaev and @edusperoni. Nevertheless, we appreciate your time and effort and we hope you will continue to contribute to NativeScript in the future. You can sign up in the form here https://goo.gl/forms/jkOpclSNMHeaRg4B2 so we can send you some stickers as a small token of our gratitude. |
What is the current behavior?
The asynchronous methods of
file-system(i.e. writeText), are executed on the main UI thread. This can lead to poor performance (i.e. UI thread freezing) when handling large chunks of data. (See #2239)What is the new behavior?
All asynchronous methods are dispatched to a Worker, freeing up the main thread. The Worker is only created once a call to one of these methods is made.
By default the Worker will close after a period of inactivity, I've arbitrarily set this period to 2 minutes. But developers are able to turn this inactivity observer off and
terminateat their own time by using the newworkersub-module offile-system.For now the
workermodule only provides aterminatemethod to kill the Worker, and akeepAlivemethod to prevent the default close on inactivity behaviour. But we could expand on this later (allowing devs to set their own period etc...).keepAliveis called the Worker will still be closed if the application raises alowMemmoryEvent, or the application itself is closed.Closes #2239