Hi,
I just pushed a patch to git which will change how timeouts are handled
on all modern linux setups. It will now use timerfd to generate regular
activity on a file descriptor when a timeout needs to be processed.
libusb_get_next_timeout() will always return 0, so the fiddlyness of
having to adjust your poll()/select() timeout based on when libusb next
has to process a timeout goes away. All events are now completely
file-driven. Yay.
Also, given that Darwin handles timeouts internally too, we are at the
stage where we can say that with libusb's current OS support, the
libusb_get_next_timeout() dance is only needed on "legacy" platforms.
(for those old setups, I'm considering adding a thread which would
generate activity on an internal file descriptor when there's a timeout,
this would eliminate the dance altogether and make the code flow nicer)
Testing hugely appreciated...
Going forward, I want to increase the libusb_handle_events() timeout to
60 seconds, and then to unlimited, which basically means that we have to
be sure that the event handling stuff is working perfectly. (if it's not
then right now it usually sorts itself out after the 2 second timeout,
so increasing that will help us see issues)
Daniel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel
