[haiku-commits] Re: haiku: hrev53945 - src/add-ons/kernel/drivers/disk/nvme src/system/kernel headers/private/kernel src/tests/add-ons/kernel/kernelland_emu
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 16 Mar 2020 09:04:49 -0400
On Mon, Mar 16, 2020, 3:44 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
Am 07/03/2020 um 22:27 schrieb waddlesplash:
1728b8c7778d: kernel: Rework ConditionVariableEntry destruction.
It is no longer an error to destroy a ConditionVariableEntry
that is still attached to a ConditionVariable; it will
now be implicitly detached in that case.
Don't you just have to call NotifyAll() before destroying the condition
variable, and make sure the entries don't add themselves again?
In either case, you'll have to make sure that it exits gracefully, so
I'm not sure there is much of a benefit (although I don't mind this API
change in any case).
Am I missing anything?
Yes, that's not what this change is about at all. This change is about the
case where the ConditionVariable is still alive, but we want to return from
whatever function has the Entry without waiting on it.
That is, something like this:
ConditionVariableEntry e;
... attach to variable ....
if (waitingOnWhateverCondition)
return;
In this case, the condition we were waiting on finished between when we
attached the condition variable and when we were going to Wait() on it, so
there is no need to wait at all. Before this commit, this code was not
valid, and now it is.
-waddlesplash
Other related posts:
