Skip to content

Define ownership of sub-receivers #432

Open

Description

@llucax

Now that close() is part of the receiver interface, we need to be more clear and consistent about when and who closes sub-receivers.

Examples of objects that close the source receiver:

  • Receiver.filter()
  • Receiver.map()
  • merge()/Merger

Examples of objects that don't:

  • LatestValueCache
  • select()

For me the most clear approach would be that objects always take ownership of the source receiver and close them when they are themselves disposed, but to be able to do this and still be flexible, we probably need to resurrect the clone idea (#382), so if you want to also keep a copy of the original receiver, you can do so. Of course, this also opened a lot of questions, so not trivial.

Activity

  1. added this to the Untriaged milestone on Jun 24, 2025
  2. llucax commented on Sep 15, 2025

    @llucax
    ContributorAuthor

    Random idea. Maybe we can have some idiom to delegate ownership, like merge(recv1, borrow(recv2)), so recv1 will be closed when merge is closed but recv2 will be left untouched.

    I think closing by default (so giving the wrapper receiver ownership of sub-receivers) is the safest choice, as using the wrong ownership passing will explode earlier than if we borrow by default, in which case things might just leak silently.

  3. llucax commented on Feb 18, 2026

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:enhancementNew feature or enhancement visitble to users

    Fields

    Priority

    None yet

    Effort

    None yet

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions