Summary:
As part of my campaign to get `HHWheelTimer` away from intrusive ref-counting semantics, (cf.
D3237530), I am redefining `HHWheelTimer::SharedPtr`. It is now a true `std::shared_ptr`. This will break clients that attempt the following:
HHWheelTimer::UniquePtr timer1{HHWheelTimer::newTimer()};
HHWheelTimer::SharedPtr timer2{timer1};
In the past, that code would compile, because `timer2` could use the intrusive ref-counting, and `timer1` would still be valid. After this change, the second timer would need to be initialized with `std::move(timer1)` instead. The `UniquePtr` is starting to actually be unique.
There is only one place in the code that actually tries to do such a copy. It's in a test, which I have changed. Any other instances of that behavior would create a compilation error, so it's impossible for one to be overlooked.
Reviewed By: djwatson
Differential Revision:
D3337038
fbshipit-source-id:
085e4da41c9a142d253a1ac0b1dd0fc508dff704
public:
// This type has always been a misnomer, because it is not a unique pointer.
using UniquePtr = std::unique_ptr<HHWheelTimer, Destructor>;
- using SharedPtr = IntrusivePtr<HHWheelTimer>;
+ using SharedPtr = std::shared_ptr<HHWheelTimer>;
template <typename... Args>
static UniquePtr newTimer(Args&&... args) {
EXPECT_EQ(1, tt.canceledTimestamps.size());
}
-TEST_F(HHWheelTimerTest, SharedPtr) {
+TEST_F(HHWheelTimerTest, IntrusivePtr) {
HHWheelTimer::UniquePtr t(
HHWheelTimer::newTimer(&eventBase, milliseconds(1)));
t->scheduleTimeout(&t1, milliseconds(5));
t->scheduleTimeout(&t2, milliseconds(5));
- HHWheelTimer::SharedPtr s(t);
+ DelayedDestruction::IntrusivePtr<HHWheelTimer> s(t);
s->scheduleTimeout(&t3, milliseconds(10));