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

feat: make sign queue use less shared state #91

Merged
merged 59 commits into from
Jan 8, 2025

Conversation

ChaoticTempest
Copy link
Contributor

Makes the sign queue less contentious with indexer. This allows signature manager to progress without indexer taking up the write lock for too long.

This makes it so that sign queue only gets created in the SignatureManager, where a channel (sign_tx, sign_rx) is create between the indexer and the protocol loop. The sign_tx is used by the indexer to send messages over the channel to sign_rx which is acquired by the SignatureManager on creation and organizing of message requests

ChaoticTempest and others added 30 commits December 3, 2024 04:13
…pc into phuong/chore/cleanup-testing-interface
…pc into phuong/chore/cleanup-testing-interface
…pc into phuong/chore/cleanup-testing-interface
…pc into phuong/chore/cleanup-testing-interface
volovyks
volovyks previously approved these changes Jan 8, 2025
Copy link
Contributor

@volovyks volovyks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure if this is a narrow place, but it makes sense overall. We will need to implement such a design for messages.

I have a feeling that we will keep sign requests in Redis, but it's a good solution for now.

pub fn new() -> Self {
Self::default()
pub fn channel() -> (mpsc::Sender<SignRequest>, mpsc::Receiver<SignRequest>) {
mpsc::channel(MAX_SIGN_REQUESTS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would the behavior be if we got more than 1024 requests? Will they be dropped or wait to be added?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe they will be dropped

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, they'll be dropped but we'll have a whole entire sweep about adding these configs to the contract when we have more demand for it

ppca
ppca previously approved these changes Jan 8, 2025
pub fn new() -> Self {
Self::default()
pub fn channel() -> (mpsc::Sender<SignRequest>, mpsc::Receiver<SignRequest>) {
mpsc::channel(MAX_SIGN_REQUESTS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe they will be dropped

Base automatically changed from phuong/feat/protocol-as-task to develop January 8, 2025 19:04
@ChaoticTempest ChaoticTempest dismissed stale reviews from ppca and volovyks January 8, 2025 19:04

The base branch was changed.

ppca
ppca previously approved these changes Jan 8, 2025
@ChaoticTempest ChaoticTempest force-pushed the phuong/feat/sign-queue-channel branch from e80f62e to 5a70c08 Compare January 8, 2025 22:11
@ChaoticTempest ChaoticTempest merged commit b263fc5 into develop Jan 8, 2025
2 of 3 checks passed
@ChaoticTempest ChaoticTempest deleted the phuong/feat/sign-queue-channel branch January 8, 2025 23:27
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.

3 participants