On Sun, 16 Feb 2014, Phil Dibowitz wrote: >> I don't think that is strange. I think what happened in this case was - >> we got busy and queued up five packets. Then we read all of them and got >> caught up. So, at that point we're caught up and now blocking, waiting on >> the read thread to wake us up. The next few packets are received while >> we're waiting for them. But for some reason we still lost some. > > How did we pop a 6th packet off of the queue if we never queued one?
I don't know exactly where all your debug statements are to be able to tell exactly what is going on. My assumption was that, after the 5th packet, we were in the situation where the the thread doing hid_read_timeout() was waiting on the one reading the packets, so the queue never got bigger than one. >> I did a little bit of looking around and it looks like the cause may be >> the HID driver only allowing one pending read to be in progress. If the >> run loop gets busy and doesn't return quickly, packets may still get lost. >> See this: >> https://groups.google.com/forum/#!msg/darwin-usb/k4AraqqCRfg/5qG0P9Tx6NwJ > > It's unclear to me what the solution here is... it seems like they're saying > have another thread that just constantly reads, i.e., "be faster" ? It wasn't clear to me that there actually *is* a solution. I don't know what else the Run Loop is doing besides calling hid_report_callback when it needs to. ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
