-
Notifications
You must be signed in to change notification settings - Fork 326
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
Is this gem is threadsafe? #305
Comments
With Ruby-3 Ractors replace threads 'conceptually'. The latter requires gems such as Faraday to be Scheduler aware. |
Would you ever change the network in production during runtime across threads? |
Yeap, I am. I am dealing with multiple networks though this gem |
do you mind explaining why you need to switch networks in production? i would love to hear some experience and learn a usecase |
Sure. We provide swapping platform on the web and we are generating multisig addresses. Final multisig address is based on the network magic values. It all happens in the same app. We are using unicorn, which relays on threads. Some tasks are happening asyncronously, as they take time and we relay on this regards on Sidekiq. Currently we have to switch network for the whole app each time. We can figure out some locking mechanism to ensure there won't be any interference from other threads or we can switch to other application server and to other job processors, but that all are workarounds. IMHO network configurations should be defined per instance and not per class. That would solve an issue. |
I was checking out the codebase and come to the conclusion that this gem might not work well with threaded applications. For example, performing parallel tasks in Unicorn or Sidekiq might cause a hard to debug issue.
I came to this conclusion after I discovered the way how the network is set up.
So my question is, are there any plans to make this gem thread-safe? or perhaps would such changes be welcomed?
The text was updated successfully, but these errors were encountered: