Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Optionally support parking_lot within global allocators.
This adds a feature to support using parking_lot locks in `#[global_allocator]` implementations. The main hazard is parking_lot calling into the global allocator, and then the global allocator calling back into parking_lot, at a point where parking_lot is not prepared to be re-entered on the same thread. There are currently two places where this comes up: - When a new thread is created, parking_lot needs to allocate space in its hashtable for the new thread. It uses the global allocator to allocate this space, and if the global allocator uses parking lot, it doesn't work because the hashtable is not ready for the new thread yet. - If the new hashtable is allocated while bucket locks are held, and the global allocator attempts to acquire a parking lot lock, it deadlocks because all the buckets are locked. For the first, this adds a new `reserve` function, defined when the "reserve" feature is enabled. This allocates space in the hashtable, and if users call it before each thread creation in the program, parking_lot won't ever need to call `grow_hashtable` on new threads. This is admittedly awkward to guarantee in general, however it's not a problem in my own use case. And this function might also be useful in cases where users want to create a pool of threads all at once, to reduce temporary allocations, leakage, and rehashing. However, I'm open to other ideas here. For the second, when "reserve" is enabled, `create_hashtable` will allocate the new `HashTable` before locking all the bucket locks, to avoid deadlock if allocating the `HashTable` attempts to take a lock.
- Loading branch information