I am exploring using
fdb_future_set_callback in my bindings.
Assuming a scenario where, callback has not been executed. If I were to call
fdb_future_destroy in application thread
T1. Is it the case that
fdb_future_destroyreturns in thread
T1, the callback would not get executed in any threads.
Given the above comment (which I might be misunderstanding), this is unlikely, but I want to confirm anyway.
Basically if I have the guarantee, callback will not get executed after
fdb_future_destroyhas been called, then I can deal with memory backing
fdb_future_destroyhas been called.
The above comment seems to hint (again, I could be wrong), that calling
fdb_future_destroywill cause the callback to run either in
T1or the network thread.
This approach seems to indicate a design where once
fdb_future_set_callbackhas been called, we are guaranteed to get a callback irrespective of whether the future gets prematurely destroyed or successfully resolves.
During normal execution, when the future resolves, the callback will get executed. However, if
fdb_future_destroygets called, before the callback has had a chance to get called, we would still get a callback.
For most futures,
fdb_transaction_destroywill implicitly call
fdb_future_destroyhence trigger the callback, if it hasn’t already been triggered.
However, in case of watch future, after the transaction has been committed, this link between
fdb_future_destroyis severed. So, after the transaction has been committed, the only way to trigger the watch future callback would be if -
fdb_future_destroygets called, or if the watch future resolves.
Am I understanding the semantics of callback correctly? Please let me know if there are any other edge cases, that I might not be thinking about.