device filtering support

[Vitali Lovich]

I have a single-threaded asynchronous Qt app (i.e. I don't launch any threads on my own) using libusb with libusbk running with almost no code changes from the OSX/Linux implementation (on Qt there's a slightly different class for Windows events).  I mentioned this already on the libusb mailing list before.  See https://github.com/vlovich/libusb/tree/win32-poll - the fd's returned work with GLib & Qt.  I'm guessing there's probably a way to get them working with libev/libevent too.

My point is I fail to see the fundamental concern people have with keeping the select API as is (just fixing it so that it's possible to operate correctly on windows).  It integrates way more nicely than callbacks too & it's easier to maintain thread-safety.

-Vitali
 
On Feb 4, 2012, at 8:50 AM, Michael Plante wrote:

> Segher Boessenkool wrote:
>>> select() is portable just fine; you just don't have a fast
>>> implementation of it on your platform.
> 
> 
> No, it's not.  I brought this up when Windows support was first being
> seriously discussed a couple years ago.  A form of select() is implemented
> on Windows, but only for network sockets.
> 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).a
> spx>
> 
> Everything else goes through a different set of APIs,
> WaitForMultipleObjects() and friends:
> 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).a
> spx>
> 
> I think you are extrapolating someone's statement about certain other APIs.
> Not all POSIX APIs exist on Windows.
> 
> Regards,
> Michael
> 
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx