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

Fix auto-cancelled Sinks.many() accepting emissions #3725

Closed

Conversation

kaqqao
Copy link

@kaqqao kaqqao commented Feb 12, 2024

Fixes #3715

I don't know if this is indeed the correct thing to do, but it does help demonstrate the situation and a possible solution.

@kaqqao kaqqao requested a review from a team as a code owner February 12, 2024 13:24
@pivotal-cla
Copy link

@kaqqao Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

1 similar comment
@pivotal-cla
Copy link

@kaqqao Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@kaqqao kaqqao force-pushed the 3715-no-emissions-after-sink-autocancel branch from 893c692 to 1c62ddb Compare February 12, 2024 13:25
@pivotal-cla
Copy link

@kaqqao Thank you for signing the Contributor License Agreement!

Copy link
Member

Choose a reason for hiding this comment

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

Please also run spotlessApply task for this file.

Copy link
Member

@chemicL chemicL left a comment

Choose a reason for hiding this comment

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

Thanks so much for the effort so far! 🎉

I think the proposed implementation which checks for cancellation upon emission attempts looks simple and elegant. Unfortunately, I'm not sure it's correct. It would definitely improve the situation. However, I am worried about potential races. As I understand this improvement would prevent unnoticed leaks of values that end up in the queue despite having the sink already unusable. In concurrent scenarios, with the proposed implementation I think there is a risk that the cancellation is about to be triggered while an item is offered.

T1: cancelling thread
T2: emitting thread

Timeline:

T1: ---------------------------- L607:terminate() -- L610:q.clear() ------------------->
T2: L253:isCancelled()-> false -------------------------------------- L279:q.offer(t) ->

Now t is in the queue and nothing will remove the reference.

As far as I understand, the access to this Sink implementation is serialized however only from the producer perspective, so this race is possible. Probably you can confirm that using a JCStress test (it would be neat to add one for this case).

Do you agree about the risk? Would you be willing to verify and improve the implementation? Thanks in advance for your effort!

@chemicL
Copy link
Member

chemicL commented Mar 20, 2024

@kaqqao are you still interested in this?

@chemicL
Copy link
Member

chemicL commented Apr 11, 2024

Closing due to lack of activity. Please reopen if you'd like to follow-up.

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.

Auto-cancelled Sink still accepts emissions
3 participants