Skip to content
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

Stop re-using NthIndexCache to avoid ABA problem #136

Merged
merged 1 commit into from
Jun 26, 2023
Merged

Stop re-using NthIndexCache to avoid ABA problem #136

merged 1 commit into from
Jun 26, 2023

Conversation

adamreichold
Copy link
Member

@adamreichold adamreichold commented Jun 26, 2023

I am really really sorry for asking for a release, but I fear we already need version 0.17.1 because I made a mistake when adding the thread-local NthIndexCache:

I just noticed that the NthIndexCache is internally keyed on the pointer to the selectors themselves which I think opens this up for an ABA problem, i.e. after dropping a selector and allocating a new one at the same address but with different content, the cache might result in incorrect matches.

Hence, I just avoided re-use completely which is certainly correct if unnecessarily inefficient, but I fear proper re-use would need to be user-visible.

I just noticed that the NthIndexCache is internally keyed on the pointer to the
selectors themselves which I think opens this up for an ABA problem, i.e. after
dropping a selector and allocating a new one at the same address but with
different content, the cache might result in incorrect matches.

Hence, I just avoided re-use completely which is certainly correct if
unnecessarily inefficient, but I fear proper re-use would need to be
user-visible.
@adamreichold adamreichold marked this pull request as draft June 26, 2023 17:17
@adamreichold
Copy link
Member Author

Let's make this a draft and store the cache within the Selector struct. This should probably tie its lifecycle to that of the selector while still giving a chance of reusing e.g. during iteration and avoids the overhead of accessing TLS. It just means I need to manually implement some boiler plate traits...

@adamreichold
Copy link
Member Author

adamreichold commented Jun 26, 2023

Ok, so avoiding TLS is not possible without messing up the API because nobody gets mutable access to Selector, but re-use is still possible by tying the lifecycle to that of the selector using the thread_local crate, thereby avoiding the ABA problem while still enabling the cache to be effective.

I added this as a separate commit though, so that it can be easily dropped if we decide to go for the obviously correct if less efficient variant instead.

@adamreichold adamreichold marked this pull request as ready for review June 26, 2023 17:35
@adamreichold
Copy link
Member Author

Aaaaand back again because it is not just the addresses of the selectors, but the cache also uses selectors::OpaqueElement which is basically the address of an element which means the same ABA problem if the same selector is used with multiple documents allocated at the same address.

Let's just drop the complexity and use the obviously correct approach. Sorry for the mess and the back and forth...

(I guess this might even be faster if no nth-index selectors are used because the TLS goes away.)

@cfvescovo
Copy link
Member

I am really really sorry for asking for a release, but I fear we already need version 0.17.1 because I made a mistake when adding the thread-local NthIndexCache

It's my fault too, I should have caught that in my review this morning
Anyway, don't worry, I will release an hotfix ASAP

Let's just drop the complexity and use the obviously correct approach.

Agreed.

@cfvescovo cfvescovo merged commit 6ddb0ac into rust-scraper:master Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants