On 20 April 2011 12:16, John Obbele <john.obb...@gmail.com> wrote: > On Tue, Apr 19, 2011 at 10:36:50PM +0200, Bas van Dijk wrote: >> Great! I have wished for an asynchronous implementation since version >> 0.1 of usb but didn't really had a need for it nor the time to >> implement it. However recently at work I have begun using my usb >> library in an application which should run on a resource constraint >> device. So any CPU cycles saved by using an asynchronous >> implementation is a win. Since we both have a need for it maybe we can >> work together? > > Yes. Your help is very welcomed and I was hoping to integrate the > code with System.USB anyway. > > Tight resource constraint and performance are not really my > priorities (I'm trying to get isopackets transfers), so my code > is far from being optimal. But at least, I've got some dumb > control read and write requests working, that can be a start ,)
Indeed, support for isochronous transfers is the only thing still missing from the usb library. Having direct support for asynchronous transfers allows to add it. >> > The issues are: >> > >> > 1) I don't know how to expose the asynchronous API to Haskell. (How would >> > you 'functionalize' it ?) >> >> I also started with trying to come up with an asynchronous _interface_ >> but realized that's probably not what users need. An asynchronous >> interface is difficult to program against. However an asynchronous >> _implementation_ is desirable over a synchronous one because of >> efficiency. >> >> [... fast-forwarding ...] >> >> What we actually want is a synchronous interface with the same API as >> we have now but with an implementation that uses the asynchronous >> interface from libusb and integrate that with the new GHC event >> manager. > > Yep ! The asynchronous stuff is a necessary burden, but on the > implementation side only. Client in Haskell should not have to > think to much about callbacks. > > I'm just discovering the GHC event manager. It looks fine and I > will try to replace my Epoll bindings with it. If I can in the > same time, I'll try to merge what I've done with the source code > available on your github ... but no promise since I've mainly > worked with low-level bit twiddlings. I have a first implementation of an asynchronously implemented 'control' function ready in the 'async' branch: https://github.com/basvandijk/usb/tree/async It differs slightly from my previous sketch in that I setup the event handling in the newCtx function. > You schematic code for control packets is ok, but the hard part > will probably be in managing concurrent requests (from multiple > forkIO computations or from a background iso-packets > communication) and then redispatching processed events from > libusb back to Haskell. > ... and this without forgetting something to cancel requested URB :( I haven't implemented asynchronous transfers yet that actually transfer user data let alone isochronous transfers. (These are next on my list though). However I don't think concurrent requests are hard. Each request has it's own transfer structure. When a transfer completes the blocked thread that is executing the request gets woken up and continues. Regards, Bas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe