[vbox-dev] vgdrvIoCtl_CancelAllWaitEvents inconsistent behavior ?
Hans de Goede
hdegoede at redhat.com
Tue Jul 4 12:24:49 UTC 2017
On 04-07-17 11:46, Michael Thayer wrote:
> Hello Hans,
> 04.07.2017 08:55, Hans de Goede wrote:
> [Discussion of inconsistent wait event cancelling code in VBoxGuest.]
>> So some remarks about this, I was thinking that *maybe* the old
>> behavior is on purpose, imagine the following:
>> 1) cancel, no waiters, pSession->fPendingCancelWaitEvents get set
>> 2) the thread for which the cancel was intended stops, without ever
>> calling into vgdrvIoCtl_WaitEvent again and so does not clear
>> the fPendingCancelWaitEvents flag
>> 3) (much) later a new thread in the same session starts waiting
>> old behavior: new thread sees an empty event, goes back to
>> new behavior: new thread sees a VERR_INTERRUPTED -> and stops
>> ? (note I've not looked at the userspace code).
> I think you are reading too much intelligent design into the interface.
> I was the guilty person who created it, long ago, and I don't think I
> thought it through sufficiently well at the time. That said, I don't
> think I wrote the current implementation code. I looked at the
> user-space code I mentioned again, and actually realised that it does
> handle the old (and the new) code. Testing seems to confirm this.
Ok, so you're saying that the best thing todo for a rewrite is for
all waiters to always exit with VBOXGUEST_WAITEVENT_INTERRUPTED ? On
Is the fPendingCancelWaitEvents flag really still necessary if there
are no waiters ? And won't this cause issues for new waiters? Or will
new waiters always have a new session ?
More information about the vbox-dev