Skip to content

Conversation

@ela-kotulska-frequenz
Copy link
Contributor

This is useful for scenarios where multiple consumers need to process the same stream of messages.

This is useful for scenarios where multiple consumers
need to process the same stream of messages.
@ela-kotulska-frequenz ela-kotulska-frequenz added the type:enhancement New feature or enhancement visitble to users label Mar 27, 2025
@ela-kotulska-frequenz ela-kotulska-frequenz self-assigned this Mar 27, 2025
@ela-kotulska-frequenz ela-kotulska-frequenz requested a review from a team as a code owner March 27, 2025 12:48
@github-actions github-actions bot added part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.) part:channels Affects channels implementation part:synchronization Affects the synchronization of multiple sources (`select`, `merge`) part:core Affects the core types (`Sender`, `Receiver`, exceptions, etc.) part:utilities Affects the utility receivers (`Timer`, `Event`, `FileWatcher`) labels Mar 27, 2025
@ela-kotulska-frequenz
Copy link
Contributor Author

ela-kotulska-frequenz commented Mar 27, 2025

But I am not sure this is correct way, because fork for FileWatcher or Timer looks strange. And I don't see any use case for them.
If we agree to go with it, then I will add tests and improve the code.

@ela-kotulska-frequenz ela-kotulska-frequenz linked an issue Mar 27, 2025 that may be closed by this pull request
@shsms
Copy link
Contributor

shsms commented Mar 27, 2025

I didn't realize you were picking this already, I think the proposal needs some changes (sorry, I should have written something earlier).

fork doesn't tell if it should be a broadcast or anycast style behaviour, and users might need different things. I would prefer using experimental.Pipe for this purpose instead because then, we don't just inherit the behaviour of anycast/broadcast receivers, and don't create additional timers, filewatchers etc, but instead just broadcast their results.

@llucax
Copy link
Contributor

llucax commented Mar 28, 2025

Same here, I just wrote it as a proposal, without thinking too much about it, just so we don't forget to discuss it but I didn't think you were going to take it so fast, I guess it probably needs a bit more discussion and thought. Maybe we can discuss in the next SDK meeting.

@llucax
Copy link
Contributor

llucax commented Apr 1, 2025

BTW, from my side we didn't have to close this, only that it needed a bit more discussion. At least I think it could still be a valid approach.

@llucax
Copy link
Contributor

llucax commented Apr 1, 2025

fork doesn't tell if it should be a broadcast or anycast style behaviour, and users might need different things. I would prefer using experimental.Pipe for this purpose instead because then, we don't just inherit the behaviour of anycast/broadcast receivers, and don't create additional timers, filewatchers etc, but instead just broadcast their results.

BTW, the original proposal (I didn't check the code in the PR yet) suggested it is basically a proxy for underlaying_source.new_receiver() so if you fork a broadcast receiver, you get another broadcast receiver, if you fork a anycast receiver, you get a new anycast receiver. So I don't think this is ambiguous, at least as long as you know what type of receiver you are forking.

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

Labels

part:channels Affects channels implementation part:core Affects the core types (`Sender`, `Receiver`, exceptions, etc.) part:docs Affects the documentation part:synchronization Affects the synchronization of multiple sources (`select`, `merge`) part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.) part:utilities Affects the utility receivers (`Timer`, `Event`, `FileWatcher`) type:enhancement New feature or enhancement visitble to users

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a Receiver.new_receiver() method

3 participants