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
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
