You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Activity
llucax commentedon Sep 15, 2025
Random idea. Maybe we can have some idiom to delegate ownership, like
merge(recv1, borrow(recv2)), sorecv1will be closed whenmergeis closed butrecv2will 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.
llucax commentedon Feb 18, 2026
LatestValueCache#495