[vbox-dev] vgdrvIoCtl_CancelAllWaitEvents inconsistent behavior ?

[Hans de Goede]

Hi,

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
>> waiting
>>
>> 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
vgdrvIoCtl_CancelAllWaitEvents  ?

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 ?

Regards,

Hans