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

Allow to specify per-subsystem signal channel size #29

Merged
merged 7 commits into from
Feb 7, 2023

Conversation

vstakhov
Copy link
Contributor

This issue also addresses #28 and allows to use both message_capacity and signal_capacity in per-subsystem overrides.

@vstakhov vstakhov force-pushed the vstakhov-variable-signals-size branch from 9835307 to 75bc689 Compare January 27, 2023 10:50
@vstakhov vstakhov requested a review from drahnr January 27, 2023 10:52
/// Capacity of a bounded message channel between orchestra and subsystem
/// but also for bounded channels between two subsystems if not overriden.
const CHANNEL_CAPACITY: usize = #message_channel_capacity;

/// Capacity of a signal channel between a subsystem and the orchestra.
const SIGNAL_CHANNEL_CAPACITY: usize = #signal_channel_capacity;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the const SIGNAL_CHANNEL_CAPACITY still required?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it is used in the connector from what I see.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But shouldn't it be symmetrical at this point with the CHANNEL_CAPACITY/message_channel_capacity.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hum, I really don't know tbh. It is defined here and also here.

Copy link
Collaborator

@drahnr drahnr Jan 27, 2023

Choose a reason for hiding this comment

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

So originally I used the constants as intermediary to be able to reason better about the code and be able to see where the values come from in the generated code. We should strive for consistency.

I have to dig into the connector part again, it might be we don't know the signal capacity early enough for overriding in that case, idqr.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Connector can be specified as an external argument, so it cannot really reason about the content of the builder/orchestra structures.

Copy link
Collaborator

Choose a reason for hiding this comment

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

The remaining uses of the signal channel capacity are a hack, because we need to construct the the sender before we start creating the builder. And we need that since we need to pass the sender around to some substrate based thing. I'd have to check polkadot again to see if the connector / builder split is actually used.

We could create a custom sender like API and internally mutate the thing with a buffer. It's not pretty and quite a bit of code for a questionable gain and also debatable if that's not a misc addition.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's defer the connector part and focus on getting this PR merged

@drahnr
Copy link
Collaborator

drahnr commented Feb 3, 2023

@vstakhov let's rebase your PR and then get the commits into main

Copy link
Collaborator

@sandreim sandreim left a comment

Choose a reason for hiding this comment

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

In the context of Polkadot usecase I think we would never need this kind of override. If signals would take that much time to be processed, then something really wrong is going on and needs to be fixed.

@@ -63,7 +63,7 @@ impl<Context> Fortified {

#[orchestra(signal=SigSigSig, event=EvX, error=Yikes, gen=AllMessages)]
struct Duo<T, U, V, W> {
#[subsystem(consumes: MsgStrukt, sends: [Plinko], message_capacity: 32768)]
#[subsystem(consumes: MsgStrukt, sends: [Plinko], message_capacity: 32768, signal_capacity: 128)]
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would add test for the overrides(ensure we block when channel full) to ensure it doesn't break over time.

@vstakhov
Copy link
Contributor Author

vstakhov commented Feb 6, 2023

@vstakhov let's rebase your PR and then get the commits into main

Merged, sorry for a delay.

@drahnr drahnr merged commit ced7be6 into master Feb 7, 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.

3 participants