[Libdlo] Synchronous vs. asynchronous USB

[Phil Endecott]

Steve (Endurance) wrote:
> On 26 May, Phil Endecott <spam_from_libdlo at chezphil.org> wrote:
>> Steve (Endurance) wrote:
>> > It was also specified to be single threaded.
>>
>> That's important.  Can you explain some more?  I would hope that, for 
>> example, a program could talk to two devices using two threads, one per 
>> device, if it wanted to.  Adding some notes about thread-safety to the 
>> documentation would be a really good idea...
>
> The main point here is that no effort is made by libdlo to deal with any of
> the dlo_ API calls being reentered by a thread whilst some other thread is
> already in there doing something. So any list structures, buffers, calls
> into other libraries (libusb) and so on have no semaphores or other
> protection from getting all messed up. This isn't an oversight; it was a
> design decision to keep it simple for a single threaded application to drive.
>
> Making libdlo support multithreading isn't too hard a task, it's just
> something that hasn't been done.

Right.  There are some nasty "return pointer to function-static
variable" things in there.  Ugh.  There are also a whole load of
function-static variables that seem to be being used as temporaries
within the functions; that's rather unusual to say the least.  Was
there some concern about guaranteed operation with a fixed-size stack,
or something?

Google tells me that libusb 0.1 is not thread safe for multiple threads
accessing different endpoints on the same device.  I'm unclear whether
it is thread-safe for multiple threads accessing different devices.
libusb 1.0 is thread safe and also has an asynchronous API variant.
libdlo seems to be using the libusb 0.1 API (which exists in 1.0 as a
compatibility layer); I'm not certain of the status of libusb 1.0, but
maybe it would make sense to target that instead.  Or just use the USB
ioctls directly; that's how I've done it in the past and it's not
especially difficult.

There is a slightly simpler way to overlap USB data transmission with
other work.  libdlo could allocate a pool of URBs and fill and submit
them as needed, but not block waiting for them to complete until the
pool was empty.  I think this would work well for e.g. the JPEG decoder
that I mentioned before.


Regards,  Phil.