Re: [Libusb-devel] libusb1.0 API

[Darren G. <garnier@MIT.EDU>]

On Nov 8, 2006, at 7:50 PM, Johannes Erdfelt wrote:

> On Wed, Nov 08, 2006, Darren Garnier <garnier@MIT.EDU> wrote:
>> On Nov 8, 2006, at 6:15 PM, Johannes Erdfelt wrote:
>>> When are they ever copied back and forth? The reason these  
>>> structures
>>> exist are solely to provide an unpacked representation.
>>>
>>> They are only ever parsed once.
>>
>> Yes... OK... just saves a single parsing.. Not much.
>
> The parsing needs to happen anyway. We not only need to parse the data
> for our internal purposes, we also want to provide programmer friendly
> and portable representations of the common descriptors.
>
> Instead of making the programmer jump through hoops with packed  
> data, or
> using non-portable ways to adjust packing for structures, we provide a
> naturally aligned structure for the programmer to use.
>
> Easy and convenient.
>
>>>> 2.  The macos x client interface is entirely asynchronous.   As I
>>>> understand it, it doesn't use pthreads to do this, but it is
>>>> compatible with pthreads.  Basically, everything you request is
>>>> handled with a completion routine.
>>>
>>> What context is this completion routine executed from?
>>
>> Assuming we are talking still of the client interface, its in the
>> user context the request was made from.  I'm a little hazy on the
>> details, but its done using Core Foundation threads which are built
>> on pthreads.
>
> You have me confused now. You said it doesn't use pthreads for this
> (look at the original quote above).

Sorry for the confusion.  I either misremembered the first time, or  
they've changed the documentation over time.  (I've been doing some  
small bit of IPC work on MacOS X since Preview 1.0.   Believe me, you  
don't want to deal with the mach messaging port.)  I don't actually  
know if it uses pthreads or mach threads (or even direct calls to the  
mach messaging port...)  If it matters, I can take a peek at the  
source.  (That part of macos x is in darwin and is open source by  
apple's definition.)  I can tell you that you can use the Core  
Foundation and IOKit client calls from within a POSIX pthread  
environment.  Apple has long since deprecated all direct mach calls.


>
>> Essentially, you set up a "run loop" in a thread, register  
>> "events" to
>> it, and run the loop.  The callbacks are run when the "event" occurs.
>> So, to make calls synchronous, the current libusb implementation  
>> starts
>> a new runloop, waits for the  answer, and completes the runloop.
>>
>> You can have other threads (and pthreads) running along completely
>> ignoring the strangeness of all this to a POSIX programmer.
>> Mutexes, locking, and condition variables are available from the
>> pthread api.  Also, one can use POSIX named semaphores.  (And also
>> SysV IPC, in later versions of Mac OS X).
>
> Ick. I hate locking.
> But it is better and/or necessary for some applications.
>
> I think now more than ever we need to have an asynchronous polled
> inteface and an asynchronous callback interface (maybe built on top of
> the polled interface).
>

I don't know about other implementations, but providing these two  
interfaces on Mac OS X shouldn't be hard (although perhaps you'd want  
to leave the "built on top" to be a backend decision.)  Certainly the  
callback interface could be very lightweight.

  Also, I think if the API was clear, all locking could be done not  
by libusb but by the application programmer.

> JE
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel