Right now there is a potential issue with Callbacks that need to aquire locks; if a mechanism calls session.need_with and friends from within the closure of session.need_with a second call to Callback::callback will be issued before the first one completes. If e.g. a Mutex is aquired inside the first function call it will likely not be released by the second call, leading to a deadlock.
We should either explicitly document Callbacks not being allowed to hold locks over a call to provide or prevent mechanism from calling need_with recursively.
The latter can easily be done via type system by making need_with take &mut self, the latter is likely much harder and potentially worse from an user perspective.
Right now there is a potential issue with Callbacks that need to aquire locks; if a mechanism calls
session.need_withand friends from within the closure ofsession.need_witha second call toCallback::callbackwill be issued before the first one completes. If e.g. a Mutex is aquired inside the first function call it will likely not be released by the second call, leading to a deadlock. We should either explicitly document Callbacks not being allowed to hold locks over a call toprovideor prevent mechanism from callingneed_withrecursively.The latter can easily be done via type system by making
need_withtake&mut self, the latter is likely much harder and potentially worse from an user perspective.