4 ms·
For the same reason that keeping a shared excel file in a network disk is a bad idea. The closure can write to database, and after the call, there’s no way to
by xondono 5y ago
For the same reason that keeping a shared excel file in a network disk is a bad idea.
The closure can write to database, and after the call, there’s no way to know if it has already written, or even if it’s writing to it right now.
- valenterry 5y agoWell, without further ado that's true. But the callback could of course set a result type somewhere (so, behave similar to a future/promise) and then we could know if/when it is finished and if it was successfully, or if it's still running (or broke without an error). But that's not Rust specific, that's just plain language-independent logic no?
- xondono 5y ago> But the callback could of course set a result type somewhere [..] then we could know if/when it is finished That would be a Mutex<>, the author mentions it in the comments. This would solve the “writing at the same time issue”, but not the lifetimes, so you’d need another change. Instead of trying the mess of implementing special closures, you could just make your db static.