wpc009 commented on pull request #18475: URL: https://github.com/apache/flink/pull/18475#issuecomment-1024444960
In your version, under the same circumtance, `anyAvailable.get()` may get the obsolete object either. `AtomicReference` can not guranteen the `happen-before` relationship you want. In your version, situation is same. The original registered callback calls complete on an obsolete object. But, since the input's future is already complete. The following `registerFuture` will add an new `thenRun` to the input's future which will make the result future complete. There difference is I check the input future's state and manually complete the result future. Your version, the callback run two times, the first may miss because of the timming issue, the second will work correctly. A little larger memory footprint. Runnable object and future `UniRun` object. But the difference is minor. The result future get completed correctly, without causing the stream hang-up. You keep saying my version will not working under such circumtances. But what I say is our solution is rafly the same. Both are working solution. The difference is minor, fewer object creation in my. Maybe fewer line of code in yours. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
