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

List:       libusb-devel
Subject:    Re: [Libusb-devel] poll with libusb in cygwin
From:       Pete Batard <pbatard () gmail ! com>
Date:       2010-01-29 21:45:13
Message-ID: 4B6356E9.9090701 () gmail ! com
[Download RAW message or body]

Hi Orin, thanks for posting back on that.

On 2010.01.29 20:19, Orin Eman wrote:
> I have code that talks to a native driver, WinUSB and libusb on the Mac
> (and linux, but that got back-burnered to concentrate on the Mac).  They
> all work the same way:
> I have a single event object associated with ALL reads and another
> associated with writes.

Yeah, I had been wondering about using the same event with OVERLAPPED, 
but thought "If it's Microsoft, there's probably a big gotcha in doing 
that" so I abstained. Plus, with WaitForMultipleObjects and one event 
per OVERLAPPED, we get a more direct access to transfers that were 
signalled, and leave the OS prioritize the signalling (which may or may 
not be a good thing).

> The read thread then
> goes through through the list of posted reads, handles those that have
> completed and posts new reads.  A write thread works similarly.

So far so good.

> To use libusb, I replaced the overlapped structure with a pointer to a
> libusb_transfer structure and an event (simulated with a condition
> variable).  I put a pointer to the structure containing these in the
> lubusb_transfer structure's user_data and set a callback function.  The
> callback function casts the user_data pointer appropriately, 'sets' the
> event and marks my buffer as completed

That's not a bad idea. As you found out on your side too, any mix of 
Windows and UNIX for libusb needs to be handled at the transfer level.

> I had an existing 'timer' thread that used to wake up every so often to
> do work of its own.  Now it waits in libusb_handle_events_timeout()
> rather than WaitForSingleObject().

> There are a couple of things that could be 'improved' for my usage.
> Firstly, a LIBUSB_TRANSFER_PENDING libusb_transfer_status so I don't
> need a flag of my own.  My read thread handles ALL reads that have
> completed each time it wakes up, so it needs some way of telling if a
> given transfer is still pending.

Definitely.

> Secondly, the ability to put the event handle in the libusb_transfer
> structure rather than a callback function and a transfer flag that
> indicates that the event be set rather than the function called.

Yes, having it there would make more sense. When we get to the async 
event handling, that's probably how we'll address things. But I'm sure 
you'll participate in that process too ;)

Regards,

/Pete

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
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]