~smspillaz/folly/folly-git-master : changes

~smspillaz/folly/folly-git-master » Changes from revision 9855

From Revision 5701 to 5682

Rev	Summary	Authors	Date
5701	Fix set/unset for default folly RequestContext Fix set/unset for default folly RequestContext Summary: My guess is that if we allow to set data in the default context, we also expect set/unset to work. It currently doesn't. This fixes it (at least, the test repro passes), but not sure it's the right fix. Reviewed By: djwatson Differential Revision: D8910506 fbshipit-source-id: cedf1dd0ee91761d210137949da7477ed69fce31	Matthieu Martin	5 years ago
5700	Comments to document explicit conversions from Range Comments to document explicit conversions from Range Summary: [Folly] Comments to document explicit conversions from `Range`. Reviewed By: terrelln Differential Revision: D8921990 fbshipit-source-id: 0728e0096738f9a86eecfaa5b05d4dfbcb0533b6	Yedidya Feldblum	5 years ago
5699	Cut non-const conversion overloads from Range Cut non-const conversion overloads from Range Summary: [Folly] Cut non-`const` conversion overloads from `Range`, for both `operator T` and `to<T>`: let them be `const` member functions so that the converted-to object cannot update `Range` internal state. Reviewed By: terrelln, vitaut Differential Revision: D8921428 fbshipit-source-id: eefc14b5fe2033cac43ebc274b27bdea95388488	Yedidya Feldblum	5 years ago
5698	Fix visitContiguousRanges() for empty and single chunk conta... Fix visitContiguousRanges() for empty and single chunk containers Summary: lastOccupiedChunks has UB with an empty container, because the end() iterator itemPtr_ is null. And with a single chunk, we must enter the iteration loop. Reviewed By: nbronson Differential Revision: D8897447 fbshipit-source-id: 7e7fd06ec7a588236eebf28f43af9ef4ab2d39cd	Edwin Smith	5 years ago
5697	Fix threadlocal_detail::ElementWrapper::dispose crash due to... Fix threadlocal_detail::ElementWrapper::dispose crash due to array reallocation Summary: Fix threadlocal_detail::ElementWrapper::dispose crash due array to reallocation Reviewed By: yfeldblum, djwatson Differential Revision: D8868394 fbshipit-source-id: dc0c91250f2ffbcba7ac4f0bcf0d048e7785d65f	Dan Melnic	5 years ago
5696	Add ThreadPoolExecutor::numActiveThreads() Add ThreadPoolExecutor::numActiveThreads() Summary: ThreadPoolExecutor could dynamically adjust number of threads according to workload. Add numActiveThreads() so we can check how many active threads are actually there, while numThreads() returns the upper bound of threads. Reviewed By: djwatson Differential Revision: D8683795 fbshipit-source-id: 09f3b4ee8570e2f2f9f97e939061693f3e0639af	Yang Zhang	5 years ago
5695	hazptr: Add function to reclaim linked objects without check... hazptr: Add function to reclaim linked objects without checking hazard pointers. Summary: Add unlink_and_reclaim member function to hazptr_obj_base_linked, as an alternative to unlink() that reclaims the object if its link count is zero without checking hazard pointers. It is useful in destructors of data structures when it is guaranteed that objects are not protected by hazard pointers (e,.g., destructor of ConcurrentHashMap). Reviewed By: yfeldblum Differential Revision: D8864019 fbshipit-source-id: 618eeded45a1f8b9503569d1ceca9994ca6e317f	Maged Michael	5 years ago
5694	DeterministicSchedule: Deschedule parent threads while they ... DeterministicSchedule: Deschedule parent threads while they wait to join child threads. Summary: Eliminate while loop behavior in DeterministicSchedule::join Depends on D8789304 Reviewed By: djwatson Differential Revision: D8840276 fbshipit-source-id: f0b0db60f7bec344d021a49cec408a2604d4a1c8	Doron Roberts-Kedes	5 years ago
5693	DeterministicSchedule: Deschedule threads waiting to acquire... DeterministicSchedule: Deschedule threads waiting to acquire DeterministicMutex Summary: Eliminate spinlock behavior from DeterministicMutex::lock by descheduling threads waiting to acquire the mutex, and placing the thread local semaphore in a waitqueue for the mutex. The unlocking thread reschedules a single waiting thread if the workqueue is non empty. Reviewed By: djwatson Differential Revision: D8789304 fbshipit-source-id: 8ffe3e289c9abfe7515b678ff98f0cefef2461c0	Doron Roberts-Kedes	5 years ago
5692	Drain ManualExecutor on destruction Drain ManualExecutor on destruction Summary: For use in tests where the executor has a nontrivial lifetime but any queued jobs should be completed, have ManualExecutor drain itself before it's destroyed. Reviewed By: yfeldblum Differential Revision: D8845457 fbshipit-source-id: 7c2aa65aa27a7850ff73a93cfbe34c2248b62d26	Chad Austin	5 years ago
5691	Remove const wlock acquisition Remove const wlock acquisition Summary: Change the write acquire interface to only acquire write locks on non-const `Synchronized` instances. This reflects the intention of mutation associated with a write lock. Reviewed By: yfeldblum Differential Revision: D8851208 fbshipit-source-id: 5be9d2e4a38d25632430a9b6c981b6e7f8412daa	Aaryaman Sagar	5 years ago
5690	Fix broken opt build due to "error: unused variable 'rv'" Fix broken opt build due to "error: unused variable 'rv'" Summary: Fix broken opt build due to "error: unused variable 'rv'" Reviewed By: yfeldblum Differential Revision: D8883701 fbshipit-source-id: 2a832cfea0bd9cbca63a8d5c2c8d7127593728af	Dan Melnic	5 years ago
5689	Remove const folly::Synchronized upgrade lock acquire Remove const folly::Synchronized upgrade lock acquire Summary: Users acquiring upgrade locks should only be allowed to lock the synchronized object when it is non-const. Because an upgrade locks are permitted to transition to write locks when mutation is required. At which point non-const access is often required on the Synchronized object. Reviewed By: yfeldblum Differential Revision: D8654360 fbshipit-source-id: c2a6574bd880db0d8e4c90166e288f5b83542ad6	Aaryaman Sagar	5 years ago
5688	mark uses of folly::assume used to optimize placement new mark uses of folly::assume used to optimize placement new Summary: F14 currently has numerous places where folly::assume is used to help optimization on GCC < 6. These are all things the optimizer should be able to deduce itself, so it would be nice to eventually remove them. This diff marks them with TODO(T31574848), as well as removing two occurrences in F14Table that duplicated an assume in F14Policy. Reviewed By: yfeldblum Differential Revision: D8849832 fbshipit-source-id: e88143b4d29f1a633b51467206c6fb6afd1cd296	Nathan Bronson	5 years ago
5687	Remove the ' ' prior to : in folly::json's pretty output. Remove the ' ' prior to : in folly::json's pretty output. Summary: Remove the ' ' prior to : in folly::json's pretty output - this improves consistency with other JSON formatters. Reviewed By: yfeldblum, luciang Differential Revision: D8843977 fbshipit-source-id: 1d5c84d7d3806ad8752b619ffe23101f7f103683	Nick Cooper	5 years ago
5686	UnboundedQueue: Add cleanup of remaining items at destructio... UnboundedQueue: Add cleanup of remaining items at destruction. Summary: - Add cleanup of remaining items, if any, at destruction. - Add test. Reviewed By: davidtgoldblatt Differential Revision: D8860966 fbshipit-source-id: e3ab2e6ff31e08d91aa20c8c058471823c722a38	Maged Michael	5 years ago
5685	hazptr: Add test to detect no reclamation, without calling c... hazptr: Add test to detect no reclamation, without calling cleanup. Summary: Add test to detect no reclamation (without calling hazptr_cleanup). The test retires a number of objects that would trigger bulk reclamation. One or more objects are expected be reclaimed. The number of retired objects must be greater than or equal to hazptr_domain::kThreshold to expect reclamation to happen. Reviewed By: yfeldblum Differential Revision: D8849957 fbshipit-source-id: ef590af21a55348ed0ed72be3637853eceb21cbc	Maged Michael	5 years ago
5684	remove lvalue-qual Future::get(...) remove lvalue-qual Future::get(...) Summary: This is part of "the great r-valuification of folly::Future": * This is something we should do for safety in general. * Using lvalue-qualified `Future::get(...)` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect. * Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get()`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising. * Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`. * Note: `get(...)` refers to `get()` and `get(Duration)`. Reviewed By: yfeldblum Differential Revision: D8710296 fbshipit-source-id: ae201af1928eb2f6a2897c9b7db884393b36b910	Marshall Cline	5 years ago
5683	hazptr: Fix hazptr_priv::push_all_to_domain to try reclamati... hazptr: Fix hazptr_priv::push_all_to_domain to try reclamation when not in dtor Summary: The most recent change had a bug that prevents all calls to hazptr_priv::push_all_to_domain from trying reclamation, instead of preventing that only when called from the destructor of hazptr_priv and during reclamation. Reviewed By: davidtgoldblatt Differential Revision: D8849738 fbshipit-source-id: 15a27e8d4a88288179609e8cf179bc8c10c96b90	Maged Michael	5 years ago
5682	optimize first insertion into F14 hash table optimize first insertion into F14 hash table Summary: This diff performs several micro-optimizations that improve the lifecycle of a single-element F14FastMap or F14FastSet by about 10% (in a single-threaded microbenchmark). Lifecycle here means construction, insertion of one entry, and then destruction, so it includes one malloc and one free. Reviewed By: yfeldblum Differential Revision: D8771446 fbshipit-source-id: 95d59f32de5a450b16ecdcb0e39b7f566ce797da	Nathan Bronson	5 years ago