211 + [this] { guard_lock = std::move(std::unique_lock<decltype(guard)>{guard}); },
212 + []{});
It seems strange that if I were to call:
lock();
unlock();
lock()
The second lock call would block, because we haven't called the callback, which is what will end up releasing the lock.
594 + CallerAutoLock caller_lock{ctx.lock, ctx.unlock};
Could mir/raii.h help reduce diff? (and don't need CallerAutoLock)
99 + virtual std::unique_ptr<FrameDroppingPolicy> create_policy(std::function<void()> const& drop_frame) const = 0;
119 + virtual std::unique_ptr<FrameDroppingPolicy> create_policy(
120 + std::function<void()> const& drop_frame,
121 + std::function<void()> const& lock,
122 + std::function<void()> const& unlock) const = 0;
I guess I'd rather just keep one function (the latter), and 3 parameters in create_policy seem like they're becoming an interface that meets the requirements of BasicLockable.
211 + [this] { guard_lock = std::move( std::unique_ lock<decltype( guard)> {guard} ); },
212 + []{});
It seems strange that if I were to call:
lock();
unlock();
lock()
The second lock call would block, because we haven't called the callback, which is what will end up releasing the lock.
594 + CallerAutoLock caller_ lock{ctx. lock, ctx.unlock};
Could mir/raii.h help reduce diff? (and don't need CallerAutoLock)
99 + virtual std::unique_ ptr<FrameDroppi ngPolicy> create_ policy( std::function< void()> const& drop_frame) const = 0; ptr<FrameDroppi ngPolicy> create_policy( void()> const& drop_frame, void()> const& lock, void()> const& unlock) const = 0;
119 + virtual std::unique_
120 + std::function<
121 + std::function<
122 + std::function<
I guess I'd rather just keep one function (the latter), and 3 parameters in create_policy seem like they're becoming an interface that meets the requirements of BasicLockable.