Re: [Libusb-devel] win32 poll emulation documentation

[Pete B. <pe...@ak...>]

On 2011.09.14 09:02, Vitali Lovich wrote:
> I disagree about that.

I tend to disagree about it too (Re: "HANDLE is a Windows local concept,
so it doesn't fit so well in a portable API"). Personally my preference 
would be for libusb_pollfd to return a list of {Windows HANDLE | POSIX 
fd} unions. This is an API change that will require POSIX users to 
rewrite their apps, so can't be done before 2.0/3.0, but nothing too 
dramatic so I think this is the most effective way (KISS).

Having to define HANDLE for non Windows platforms is not a major issue 
in my view (especially as it typedefs to void*, but I'd rather go with 
an explicit HANDLE in the union than void*), and as Vitali pointed out, 
this is probably the less intrusive way to bring async event handling to 
all platforms, though I disagree with the approach of casting a HANDLE 
into an fd, and would have to rally with Peter that it is a hack, albeit 
one that is aimed at keeping the API untouched and that I could 
temporarily go with for the 1.0.x API, until such time as we can 
introduce a more proper approach in 2.0/3.0.

The current API forces Windows to use an fd, which is a construct that 
is actually alien to Windows. It is only there because various 
compatibility layers, some of which are provided by Microsoft 
themselves, have been added to the Windows API due to the large number 
of developers either importing or being more familiar with POSIX code. 
 From looking at Windows applications, I think this was the right 
approach in terms of helping developers so I don't see much of an issue 
with a very limited occurrence of the reverse to happen for pure POSIX 
platforms.

You may be able to find third party APIs that abstract some of it to 
make it cross platform, but if you're developing an app that doesn't use 
one of those, you will have to differentiate between Windows and POSIX 
in your event loop as there does not currently exist a de-facto 
abstracted construct that can apply for both. Thus spending a lot of 
time abstracting the concept of fds and HANDLEs across libusb supported 
platforms, or focusing on reusing an fd-only aware API doesn't seem like 
that worthwhile an endeavour to me.

As such, I don't think we should try to introduce our own abstracted 
version, or cast a HANDLE into an fd, but just go with a union that can 
be used on either. But that means waiting for 2.0/3.0.

> Thus the only portability you're trying to solve is for third party
> event loops, not OS.
>
> Let's examine that shall we:
> glib - no problem - API transparent
> libevent/libev - no problem - API transparent
> Qt - not API transparent, integration possible

Other 3rd party - ?????

While I'd tend to agree with Vitali's approach of providing native 
HANDLEs on Windows, I'm a bit concerned about considering that the only 
event loops we should focus on are glib, libevent and Qt. We need to 
consider future or custom third party event loops as well, which is 
another reason to provide native HANDLEs as it is the most generic way 
for Windows. It doesn't matter if glib or libevent expects an "fd" 
source, IMO the developer should be the one converting the HANDLE 
returned by libusb to an fd according to what glib requires (which I 
believe is what you're currently doing in your patch), rather than 
libusb. It's not because glib and libevent distort the concept of fds on 
Windows to apply it to a HANDLE that we should do the same. That is, 
unless we want to endorse glib and libevent as the "right" way to do 
event handling on Windows.

Oh, and I'd be happier if pollfd were to be renamed to something more 
"portable", since Windows should use neither polling nor fds.

Regards,

/Pete