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

Routers and Selectors. Part 4 select #806

Open
emil14 opened this issue Dec 14, 2024 · 0 comments
Open

Routers and Selectors. Part 4 select #806

emil14 opened this issue Dec 14, 2024 · 0 comments
Assignees

Comments

@emil14
Copy link
Collaborator

emil14 commented Dec 14, 2024

Previous parts:

Select

Basic

Select is a selector, like match, but instead of selecting a message based on a value, it selects based on the source, or in other words, based on the order. It waits for all data senders first and then blocks until the first condition message is sent. As soon as that happens, it selects the message from the data sender corresponding to the condition sender that fired and sends the selected message to the receiver.

Unlike match select cannot have default branch because otherwise it would just send infinitely. Also select is the only selector that cannot have a sender connected to its body. All this because it doesn't have a single thing that "kicks" it - it locks on a set of conditions, each of which will kick it.

select {
    cond_1: data_sender1
    cond_2: data_sender2
    cond_3: data_sender3
} -> receiver

Example

select {
    email: 'an email was sent'
    phone: 'a phone call was made'
} -> println

One might think that this logic can be emulated with deferred connections, but that's not true. First, we would have to create several println nodes, as duplicates are not allowed. Second, deferred connections insert locks and thus create latency. Where you have branching and latency, a race condition is possible.

With Multiple Conditions on a Same Branch

Similar to match, select allows the union of multiple conditions on a single branch:

select {
    [cond_1, cond_2]: data_sender
    ...
} -> receiver

Example

select {
    [cond_1, cond_2]: 'known event occured'
} -> receiver

Unlike if, switch, and match, select is only blocked by data senders and receivers, not by all of its condition senders. This is because it does not wait for all conditions to be met; instead, it sends a message as soon as the first condition is met.

One way to think about selectors is that match maps one value onto another, while select maps an event onto a value.

Similar to previous constructs, select can have multiple receivers connected to its body. It is handled like a fan-out, which affects latency as usual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant