Skip to content
This repository has been archived by the owner on Sep 9, 2022. It is now read-only.

When updating, wait for update to complete before discarding memory used by previous filters #376

Closed
gorhill opened this issue Nov 21, 2014 · 2 comments

Comments

@gorhill
Copy link
Contributor

gorhill commented Nov 21, 2014

Currently, if an auto-update kicks in, and if it takes too long to complete (due to lists taking long to load from remote locations for example), uBlock will find itself "naked" and thus unable to block properly until the update cycle completes. This might account for reported (though rare) cases on "uBlock no longer blocking ads".

Because of the hard-coded timeout of 15s, there is a window of roughly 15s within which uBlock is at risk of failing to block if ever filter lists do not download for whatever reason.

One solution is to wait that the update to complete, then replace the old filters with the new filters in one single operation, this way the blocking engine will not find itself naked. Consequence however is that it doubles the memory footprint during the time the filters are re-loaded.

Anyways, investigate all this.

@kurtextrem
Copy link

In my opinion a short time of high memory usage is less noticeable than non-functioning, so go for the "new" approach.

@gorhill
Copy link
Contributor Author

gorhill commented Dec 20, 2014

I will go with a different approach, I will split the update cycle into two steps:

  1. fetch-cache remote resources which need updating
  2. once all is successfully updated, trigger a reload of the filters, which will cause the freshly cache versions to be used

This avoid having two non-garbage-collectable filtersets in memory, and the loading/parsing from cache is fast enough that the time window where uBlock has no filter will always be around 1 sec (i.e. very acceptable), as opposed to potentially 15s-30s in case of network/remote server issues.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants