[PATCH 09/11] complain if libusb_get_pollfds is called on Windows

[Michael Plante]

>From d3615c9bb62b8f99ec5cb62aa851a8b472520f03 Mon Sep 17 00:00:00 2001
From: Pete Batard <[hidden email]>
Date: Tue, 13 Dec 2011 21:18:10 -0500
Subject: [PATCH 09/11] complain if libusb_get_pollfds is called on Windows

Signed-off-by: Michael Plante <[hidden email]>
---
 libusb/io.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libusb/io.c b/libusb/io.c
index 58bdcdf..c4b3635 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -2397,6 +2397,8 @@ out:
  usbi_mutex_unlock(&ctx->pollfds_lock);
  return (const struct libusb_pollfd **) ret;
 #else
+ usbi_err(ctx, "external polling of libusb's internal descriptors "\
+ "is not yet supported on Windows platforms");
  return NULL;
 #endif
 }
--
1.7.3.1.msysgit.0

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

This can wait.

/Pete

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

NAK on  the patch - it actually works fine if you create a gevent
source or a qt one.  Similar other mechanisms for other event loops.
That's how I use it in my code too.

On Fri, Dec 23, 2011 at 9:04 PM, Pete Batard <[hidden email]> wrote:

> This can wait.
>
> /Pete
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Wed, Dec 28, 2011 at 12:54 PM, Vitali Lovich <[hidden email]> wrote:
> NAK on  the patch - it actually works fine if you create a gevent
> source or a qt one.  Similar other mechanisms for other event loops.
> That's how I use it in my code too.

Interesting. Could you show some examples? Thanks.

--
Xiaofan

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

Last time I looked, the API is transparent with glib - you use the
same api as you would for a pollfd.  With Qt, new
QWinEventNotifier((HANDLE)fd) & connect up the signal/slot to do what
you need (QWinEventNotifier's header isn't exported but the API is, so
either copy the header from qt source into your own or apply the patch
in qt's bug tracker & build a custom version of qt.

-Vitali

On Wed, Dec 28, 2011 at 12:38 AM, Xiaofan Chen <[hidden email]> wrote:
> On Wed, Dec 28, 2011 at 12:54 PM, Vitali Lovich <[hidden email]> wrote:
>> NAK on  the patch - it actually works fine if you create a gevent
>> source or a qt one.  Similar other mechanisms for other event loops.
>> That's how I use it in my code too.
>
> Interesting. Could you show some examples? Thanks.
>
> --
> Xiaofan

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

On Tue, Dec 27, 2011 at 10:54 PM, Vitali Lovich <[hidden email]> wrote:
> NAK on  the patch - it actually works fine if you create a gevent
> source or a qt one.  Similar other mechanisms for other event loops.
> That's how I use it in my code too.

Eh?  Yours isn't exactly a comment on the patch, even if your method
works (without looking, I'm doubtful considering how deeply we looked
into this a long time ago).  All this patch does is display an error
message.  Regardless of whether the patch is applied or not, the
function fails.  Pete thought it important (but not time-sensitive,
i.e., "can wait", and I agree) to display a message before returning
NULL.

Michael

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

Sorry - my bad.  Misread the patch.  Also, I forgot that I have a
patch in my branch that I use to have the pollfd code work on Windows
(& I've tested it fairly well on 64-bit Windows 7, so I know it works
there).

-Vitali

On Wed, Dec 28, 2011 at 1:43 AM, Michael Plante
<[hidden email]> wrote:

> On Tue, Dec 27, 2011 at 10:54 PM, Vitali Lovich <[hidden email]> wrote:
>> NAK on  the patch - it actually works fine if you create a gevent
>> source or a qt one.  Similar other mechanisms for other event loops.
>> That's how I use it in my code too.
>
> Eh?  Yours isn't exactly a comment on the patch, even if your method
> works (without looking, I'm doubtful considering how deeply we looked
> into this a long time ago).  All this patch does is display an error
> message.  Regardless of whether the patch is applied or not, the
> function fails.  Pete thought it important (but not time-sensitive,
> i.e., "can wait", and I agree) to display a message before returning
> NULL.
>
> Michael

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

On 2011.12.28 14:16, Vitali Lovich wrote:
> I forgot that I have a
> patch in my branch that I use to have the pollfd code work on Windows

Indeed you do. I've been pondering on using some of it in my branch,
and/or switching to a dual fd/HANDLE approach, but without regular
libusb releases in sight, new developments don't seem like a good
investment.

>> Pete thought it important (but not time-sensitive,
>> i.e., "can wait", and I agree) to display a message before returning
>> NULL.

Makes sense to attempt to display a clarification message whenever a
call fails, and such a message is clearly missing there.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

If we actually implement the windows-equivalent behaviour, then the
message & failure case disappear, so maybe we should make a decision
on actually merging that change upstream first?

-Vitali

On Wed, Dec 28, 2011 at 11:58 AM, Pete Batard <[hidden email]> wrote:

> On 2011.12.28 14:16, Vitali Lovich wrote:
>> I forgot that I have a
>> patch in my branch that I use to have the pollfd code work on Windows
>
> Indeed you do. I've been pondering on using some of it in my branch,
> and/or switching to a dual fd/HANDLE approach, but without regular
> libusb releases in sight, new developments don't seem like a good
> investment.
>
>>> Pete thought it important (but not time-sensitive,
>>> i.e., "can wait", and I agree) to display a message before returning
>>> NULL.
>
> Makes sense to attempt to display a clarification message whenever a
> call fails, and such a message is clearly missing there.
>
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

On Wed, Dec 28, 2011 at 3:34 PM, Vitali Lovich <[hidden email]> wrote:
> If we actually implement the windows-equivalent behaviour, then the
> message & failure case disappear, so maybe we should make a decision
> on actually merging that change upstream first?


I understand what you're saying, but I don't see that happening in
1.0.9, even IF it's as simple as you say.  We're talking one-line or
two-line changes with no substantial ripple implications, other than
bugfixes, I think.  A proper solution to the fd problem seems to be so
complicated that no one ever agreed to solving it prior to the first
"real" Windows release.  Unless you think this patch is a bad idea (as
opposed to releasing as-is, NOT as opposed to incorporating your
changes, which probably won't happen), please change the subject so
Peter doesn't feel the need to review this discussion before deciding
on this patch; Pete and I are in agreement that this one "can wait."

Michael

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

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.

-Vitali

On Wed, Dec 28, 2011 at 9:42 PM, Michael Plante
<[hidden email]> wrote:

> On Wed, Dec 28, 2011 at 3:34 PM, Vitali Lovich <[hidden email]> wrote:
>> If we actually implement the windows-equivalent behaviour, then the
>> message & failure case disappear, so maybe we should make a decision
>> on actually merging that change upstream first?
>
>
> I understand what you're saying, but I don't see that happening in
> 1.0.9, even IF it's as simple as you say.  We're talking one-line or
> two-line changes with no substantial ripple implications, other than
> bugfixes, I think.  A proper solution to the fd problem seems to be so
> complicated that no one ever agreed to solving it prior to the first
> "real" Windows release.  Unless you think this patch is a bad idea (as
> opposed to releasing as-is, NOT as opposed to incorporating your
> changes, which probably won't happen), please change the subject so
> Peter doesn't feel the need to review this discussion before deciding
> on this patch; Pete and I are in agreement that this one "can wait."
>
> Michael

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Vitali Lovich wrote:
> The only API, currently, that works on windows for users of libusb is
> the synchronous API.

I'm not convinced? Is that really so? What if I start a thread to
call libusb for event handling?


//Peter

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

Fair enough.  The one that's broken is the asynchronous polling API.

-Vitali

On 2012-02-07, at 2:34 AM, Peter Stuge <[hidden email]> wrote:

> Vitali Lovich wrote:
>> The only API, currently, that works on windows for users of libusb is
>> the synchronous API.
>
> I'm not convinced? Is that really so? What if I start a thread to
> call libusb for event handling?
>
>
> //Peter
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Vitali Lovich wrote:
> >> The only API, currently, that works on windows for users of libusb is
> >> the synchronous API.
> >
> > I'm not convinced? Is that really so? What if I start a thread to
> > call libusb for event handling?
>
> Fair enough.  The one that's broken is the asynchronous polling API.

Thanks for clarifying. Then we are on the same page!


//Peter

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

On 2012-02-07, at 11:30 AM, Peter Stuge <[hidden email]> wrote:

> Vitali Lovich wrote:
>>>> The only API, currently, that works on windows for users of libusb is
>>>> the synchronous API.
>>>
>>> I'm not convinced? Is that really so? What if I start a thread to
>>> call libusb for event handling?
>>
>> Fair enough.  The one that's broken is the asynchronous polling API.
>
> Thanks for clarifying. Then we are on the same page!

This conversation is pretty old and I'm on my phone - what page is that?

>
>
> //Peter
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Vitali Lovich wrote:

> >>>> The only API, currently, that works on windows for users of libusb is
> >>>> the synchronous API.
> >>>
> >>> I'm not convinced? Is that really so? What if I start a thread to
> >>> call libusb for event handling?
> >>
> >> Fair enough.  The one that's broken is the asynchronous polling API.
> >
> > Thanks for clarifying. Then we are on the same page!
>
> This conversation is pretty old and I'm on my phone - what page is
> that?

It's a matter of expression, which just means that we agree. :)


//Peter

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

On Tue, Feb 7, 2012 at 12:06 PM, Peter Stuge <[hidden email]> wrote:

> Vitali Lovich wrote:
>> >>>> The only API, currently, that works on windows for users of libusb is
>> >>>> the synchronous API.
>> >>>
>> >>> I'm not convinced? Is that really so? What if I start a thread to
>> >>> call libusb for event handling?
>> >>
>> >> Fair enough.  The one that's broken is the asynchronous polling API.
>> >
>> > Thanks for clarifying. Then we are on the same page!
>>
>> This conversation is pretty old and I'm on my phone - what page is
>> that?
>
> It's a matter of expression, which just means that we agree. :)

I understand the expression; I was just checking what it is that we
agree on (I've lost the context of the original thread).

>
>
> //Peter
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Vitali Lovich wrote:

> >> >>>> The only API, currently, that works on windows for users of libusb is
> >> >>>> the synchronous API.
> >> >>>
> >> >>> I'm not convinced? Is that really so? What if I start a thread to
> >> >>> call libusb for event handling?
> >> >>
> >> >> Fair enough.  The one that's broken is the asynchronous polling API.
> >> >
> >> > Thanks for clarifying. Then we are on the same page!
> >>
> >> This conversation is pretty old and I'm on my phone - what page is
> >> that?
> >
> > It's a matter of expression, which just means that we agree. :)
>
> I understand the expression; I was just checking what it is that we
> agree on (I've lost the context of the original thread).

Does your phone hide the context?

Context is that you wrote that "the only API, currently, that works
on windows .. is sync" and I asked for confirmation that async also
works, if a separate thread is created for libusb event handling.


//Peter

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel