Bug 1783190 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This was raised in bug 1675068 -- With the changes in  bug 1742438, cancellation was turned into a flag, as opposed to iterating over all requests and cancelling them one by one. 

The main issue is deleting the cache. We don't have a pointer to the cache creator because we are no longer tracking where we are in terms of processed requests on the main thread. There are three ways to solve this, I think:
* The original method: Keep a pointer on WorkerScriptLoader. If we keep a pointer to the cache creator on the WorkerScriptLoader, we will leak memory. This means we need some form of iteration, or a signal that all of the requests have been sent back to the worker to do clean up.
* Make CacheCreator initialize on the Worker side. The issue is we have some cross thread data used in the cache creator. This is likely doable, but will be more invasive. 
* Track the ScriptLoaderRunnable, and store it there. The problem with this, is we would need the WorkerScriptLoader to be aware of the ScriptLoaderRunnable, and this doesn't work for modules.
* The final option is to iterate over the ScriptLoadRequests on the worker side, and dispatch a runnable that deletes the cache and clears the promises.

I will probably go with option 4 here, as it seems least invasive.
This was raised in bug 1675068 -- With the changes in  bug 1742438, cancellation was turned into a flag, as opposed to iterating over all requests and cancelling them one by one. 

The main issue is deleting the cache. We don't have a pointer to the cache creator because we are no longer tracking where we are in terms of processed requests on the main thread. There are four ways to solve this, I think:
* The original method: Keep a pointer on WorkerScriptLoader. If we keep a pointer to the cache creator on the WorkerScriptLoader, we will leak memory. This means we need some form of iteration, or a signal that all of the requests have been sent back to the worker to do clean up.
* Make CacheCreator initialize on the Worker side. The issue is we have some cross thread data used in the cache creator. This is likely doable, but will be more invasive. 
* Track the ScriptLoaderRunnable, and store it there. The problem with this, is we would need the WorkerScriptLoader to be aware of the ScriptLoaderRunnable, and this doesn't work for modules.
* The final option is to iterate over the ScriptLoadRequests on the worker side, and dispatch a runnable that deletes the cache and clears the promises.

I will probably go with option 4 here, as it seems least invasive.

Back to Bug 1783190 Comment 0