Skip to content

Conversation

@mudlabs
Copy link
Contributor

@mudlabs mudlabs commented Jul 13, 2019

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 terminate at their own time by using the new worker sub-module of file-system.

For now the worker module only provides a terminate method to kill the Worker, and a keepAlive method to prevent the default close on inactivity behaviour. But we could expand on this later (allowing devs to set their own period etc...).

  • Note: Even if keepAlive is called the Worker will still be closed if the application raises a lowMemmoryEvent, or the application itself is closed.

Closes #2239

mudlabs added 16 commits July 13, 2019 11:39
All existing asyncronouse methods is `file-system` are dispatched to this Worker.
Components for the `file system` Worker.
Import the FSWorker object from components.
Move globally declared, but local file-system methods and variables to a _FileSystem object.
Update all methods using asynchronous methods to run on Worker thread.

And call local methods from new _FileSystem object.
All existing asyncronouse methods is `file-system` are dispatched to this Worker.
Components for the `file system` Worker.
Import the FSWorker object from components.
Move globally declared, but local file-system methods and variables to a _FileSystem object.
Update all methods using asynchronous methods to run on Worker thread.

And call local methods from new _FileSystem object.
Context is only used in worker so moved interface to worker.ts
FSJobs interface is only worker and not needed to be exported. removed from FSWorker namespace and renamed to WorkerJobs (for semantics).
@cla-bot cla-bot bot added the cla: yes label Jul 13, 2019
@PeterStaev
Copy link
Contributor

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.

@edusperoni
Copy link
Contributor

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.

@manoldonev
Copy link
Contributor

@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.

@manoldonev manoldonev closed this Oct 2, 2019
@mudlabs mudlabs deleted the file-system-thread branch October 3, 2019 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make the file-system module run in a background thread [$300]

5 participants