-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
feat: op registration during calls #3375
Conversation
dispatchers: Vec<Box<OpDispatcher>>, | ||
name_to_id: HashMap<String, OpId>, | ||
dispatchers: RwLock<Vec<Arc<Box<OpDispatcher>>>>, | ||
name_to_id: RwLock<HashMap<String, OpId>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😭 this might impact performance, hot path will require to acquire a read lock everytime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like it did in benchmarks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but they're flaky... Anyway why do you need to put dispatchers
behind the lock? In native plugin PR you already have Arc<Mutex<Isolate>>
available so you should be able to register new ops quite easily
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In most cases during dispatch we already have a lock on isolate somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see... I'm curious to see it combined with native plugins PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I'm worried about the locks too, but I think we need this functionality. Let's keep an eye on the benchmarks after this and see if there are any noticeable regressions.
( and this nice work @afinch7 )
It doesn't look like it messed with the benchmarks much at all. I think it would take something pretty drastic on the rust side to really be noticeable beyond max latency. |
prerequisite for #3372