Thanks to visit codestin.com
Credit goes to docs.rs

orx_concurrent_vec/
exclusive.rs

1use crate::{ConcurrentVec, elem::ConcurrentElement};
2use orx_pinned_vec::IntoConcurrentPinnedVec;
3
4impl<T, P> ConcurrentVec<T, P>
5where
6    P: IntoConcurrentPinnedVec<ConcurrentElement<T>>,
7{
8    /// Clears the concurrent bag.
9    pub fn clear(&mut self) {
10        unsafe { self.core.clear(self.core.state().len()) };
11    }
12
13    /// Note that [`ConcurrentVec::maximum_capacity`] returns the maximum possible number of elements that the underlying pinned vector can grow to without reserving maximum capacity.
14    ///
15    /// In other words, the pinned vector can automatically grow up to the [`ConcurrentVec::maximum_capacity`] with `write` and `write_n_items` methods, using only a shared reference.
16    ///
17    /// When required, this maximum capacity can be attempted to increase by this method with a mutable reference.
18    ///
19    /// Importantly note that maximum capacity does not correspond to the allocated memory.
20    ///
21    /// Among the common pinned vector implementations:
22    /// * `SplitVec<_, Doubling>`: supports this method; however, it does not require for any practical size.
23    /// * `SplitVec<_, Linear>`: is guaranteed to succeed and increase its maximum capacity to the required value.
24    /// * `FixedVec<_>`: is the most strict pinned vector which cannot grow even in a single-threaded setting. Currently, it will always return an error to this call.
25    ///
26    /// # Safety
27    /// This method is unsafe since the concurrent pinned vector might contain gaps. The vector must be gap-free while increasing the maximum capacity.
28    ///
29    /// This method can safely be called if entries in all positions 0..len are written.
30    pub fn reserve_maximum_capacity(&mut self, new_maximum_capacity: usize) -> usize {
31        unsafe {
32            self.core
33                .reserve_maximum_capacity(self.core.state().len(), new_maximum_capacity)
34        }
35    }
36}