Why was GCC Adapter polling implemented the way it is ?

[Arte]

Hello,

I have recently begun looking thoroughly into the Dolphin implementation, and while looking into how it handles GCC Adapter polling, I was very surprised to find the following code (Source/Core/InputCommon/GCAdapter.cpp) :

Code:

static void Read()
{
 int payload_size = 0;
 while (s_adapter_thread_running.IsSet())
 {
   libusb_interrupt_transfer(s_handle, s_endpoint_in, s_controller_payload_swap,
                             sizeof(s_controller_payload_swap), &payload_size, 16);

   {
     std::lock_guard<std::mutex> lk(s_mutex);
     std::swap(s_controller_payload_swap, s_controller_payload);
     s_controller_payload_size.store(payload_size);
   }

   Common::YieldCPU();
 }
}

This is an odd way of implementing polling, with the first implementation one would think of being periodic polling (especially since, I believe, the USB standard expects interrupt transfers to be periodic - not that it matters in the adapter's case).
Yet, as I interpret it, here we yield the CPU after each USB transfer request, and do another one when the CPU is kind enough to let this thread resume execution. (Looking at USB request block trace, with little CPU load, on my computer, this actually behaved close to periodic behavior - ~every 0.8ms)
I was unable to find an explanation of why this is done the way it is. Since this is quite critical code, I suppose there is a good and technically advanced reason for it, and was hoping whoever knows could explain me.

Thanks !

[Billiard26]

The YieldCPU is probably unnecessary as libusb_interrupt_transfer is blocking, but other than that the code seems fine. There have been a lot of hands in this file. It's been changed around quite a bit, a few times, in attempts to get better behavior.

It's possible that the yield is alleviating CPU usage in situations where libusb is in an error state and returns immediately.

And I wouldn't really agree. The code isn't that critical. 0.8ms is a long time in perspective. Even when yielding your OS is going to allow this thread to read input long before you'd notice any delay.