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

IORef and concurrency #251

Open
YuriRomanowski opened this issue Dec 19, 2022 · 0 comments
Open

IORef and concurrency #251

YuriRomanowski opened this issue Dec 19, 2022 · 0 comments

Comments

@YuriRomanowski
Copy link
Contributor

Clarification and motivation

In #234 PR we introduced IORef to keep the set of domains that ever returned 429 error code.

But there are some concerns that @Martoon-00 stated:

However, the potential issue with atomicModifyIORef' is that it may cause high contention. If we get 1000 simultaneous responses with 429 and invoke this function repeatedly, it may end up with different calls hindering each other, because AFAIU atomicModifyIORef is implemented as compare-and-set, and each thread will get value, perform S.insert computation, only to find out that during that time another thread tried to insert something and thus the result is invalidated and computation must be repeated. If this is true, we may get quadratic execution time.

Acceptance criteria

  • Set up a simple experiment and try to reproduce the issue
  • Discuss and decide whether it can harm the normal program working
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

No branches or pull requests

1 participant