youyuanwu
commented
2 months ago In the current implementation, cancelling the token will preempt any rust future immediately that is waiting for SF to complete. This might not be the desired behavior. The better behavior is that cancelling the token will not preempt futures immediately but still wait for SF to complete, and it is up to SF to respond to the cancellation request. If SF got the cancel signal, it finished the request fast with operation cancelled error code, the rust future should wait for the error code.
I will explore this in a future PR.
Implement #46 All SF rust api should have a new parameter
cancellation_token: CancellationToken. CancellationToken is taken directly from tokio_util crate, as I don't see an advantage to do a wrapping of it or creating our own implementation of cancellation token. SF treats cancellation as an advisory signal, and in user application(rust api), user can ignore the cancel signal, but it might stall SF until the operation is finished.In this PR there is only 1 proxy api and 1 bridge api has been modified to have this cancellation token, and I will create another PR to change all apis. The implementation requires new BridgeContext, oneshot Sender/Receiver, and fabric_begin_end_proxy. The original implementations are not changed in this PR but will be removed/replaced in the next PR.