Struct windows_helpers::ReentrantRefCell
source · pub struct ReentrantRefCell<T: ?Sized> { /* private fields */ }
Expand description
A RefCell
that allows to recursively retrieve a mutable reference.
Like std::cell::RefCell
, but with an additional Self::borrow_mut_reentrant()
method. (If needed, the type could call through to more of RefCell
’s other methods.)
Implementations§
source§impl<T> ReentrantRefCell<T>
impl<T> ReentrantRefCell<T>
pub fn new(data: T) -> Self
pub fn borrow(&self) -> Ref<'_, T>
pub fn borrow_mut(&self) -> RefMut<'_, T>
sourcepub unsafe fn borrow_mut_reentrant<F, U>(&self, f: F) -> U
pub unsafe fn borrow_mut_reentrant<F, U>(&self, f: F) -> U
Mutably borrows the wrapped value for the duration of the closure call, again allowing mutable borrows by means of this method inside of the closure and the functions it calls.
It borrows with std::cell::RefCell::borrow_mut()
for the outermost call, which means additional attempts to borrow during the outermost borrow, other than by means of this method, will panic. Repeated inner calls provide the mutable reference that the outermost call made available.
The function is useful when dealing with an FFI and foreign code calls into your callback with a ReentrantRefCell
at hand, you then call an FFI function and, during this call, the foreign code calls into your callback again. This happens, e.g., with window procedures on Windows when calling functions like DestroyWindow()
or MoveWindow()
in the procedure itself.
§Safety
You are responsible to only call reentrance causing functions (like FFI functions) as if they had a &mut self
parameter and wouldn’t cause a compiler error with that. I.e., you must, e.g., not borrow something mutably from the mutable reference you get, call the reentrance causing function and then continue to use the borrow from before. When used in the relevant cases, a helper function that simply demands a &mut self
parameter and just calls through to the closure from its second parameter would desirably trigger compiler errors. It’s unknown whether using such a helper function is necessary with regard to possible compiler optimizations when not using it.
Searching for “sen” (“send”/“sent”) on Windows API function doc pages seems to be a good way to check whether a function may synchronously call the window procedure.