[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libusb-devel
Subject:    Re: [Libusb-devel] [PATCH 09/11] complain if libusb_get_pollfds is
From:       Vitali Lovich <vlovich () gmail ! com>
Date:       2011-12-30 4:39:48
Message-ID: CAF8PYMjjO6tGcg0S0EPZVgEh0GDC2iTO8An6e9PWbXFFM_6hUQ () mail ! gmail ! com
[Download RAW message or body]

The only API, currently, that works on windows for users of libusb is
the synchronous API.  I know obviously that internally it's all
layered on top of the asynchronous API.  But since I built my whole
app utilizing the asynchronous API, I was SOL.  And the story on
synchronous isn't all that much better since my impression is that
there were some particularly nasty bugs that caused unnecessary
latency (& getting lower latency is easier with asynchronous APIs
anyways).

Neither here nor there - none of this discussion is meant for the
current release.

On Thu, Dec 29, 2011 at 3:45 PM, Pete Batard <pete@akeo.ie> wrote:
> On 2011.12.29 15:45, Vitali Lovich wrote:
>> That's all I was saying.  If we're going to wait on this patch
>> anyways, then solve the windows problem.  Cause without doing
>> something like I did, there is currently no mechanism for asynchronous
>> I/O to work on windows unless I'm missing something.
>
> Internal async I/O seems to work quite fine. It's only if you want to
> mix the currently internal-only libusb async events with external ones
> on Windows that you are limited, as you have found.
>
> Thus I wouldn't equate this with "async I/O does not work on Windows".
> We do have async, and are exactly at the async support stage that was
> intended for the first Windows EXPERIMENTAL release (i.e. as far as we
> can get without breaking the current API expectation for fds). Of
> course, on any other project, because we reached the stage above about 2
> years ago, we'd long have had a release and gradually achieved feature
> completion through later iterations, but this is libusb...
>
> As you may have realized, I've grown tired of adding stuff to -pbatard
> that never gets integrated/released, so I hope you'll excuse me if I
> don't exactly jump on the opportunity to add some more (even more so as
> I'd prioritize libusb0/K and hotplug over async completion, as both are
> expected to be a lot more beneficial for libusb users). As far as I'm
> concerned, discussing async finalization not only can but should wait,
> so as not to risk disturbing the current utterly dysfunctional release
> process in the slightest.
>
> Regards,
>
> /Pete
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Libusb-devel mailing list
Libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[prev in list] [next in list] [prev in thread] [next in thread]