sync and async API mixed programming caused data disorder

[lujnan]

Is there a problem with the reap_for_handle function in linux usbfs？

There are two threads A and B, A is calling libusb_control_transfer, and B uses asynchronous interrupt transfer to read data from device. A thread will callback the interrupt transfer also! Maybe B will also callback to A's control transfer. that will cause received data disorder.

        struct usbfs_urb *urb;
    struct usbi_transfer *itransfer;
    struct libusb_transfer *transfer;

    r = ioctl(hpriv->fd, IOCTL_USBFS_REAPURBNDELAY, &urb);

if the ioctl can't identify by urb type?

In different threads, synchronous and asynchronous APIs are mixed In the composite device, even if the dup(fd) method is used, there is no way to prevent different threads returning from reap_for_handle, and the threads will be scheduled by the system at this point in time, which leads to sequence disorder

[mcuee]

Does the following libusb documentation answer your question? https://libusb.sourceforge.io/api-1.0/libusb_mtasync.html

[lujnan]

My issue is the same as #1077

[mcuee]

@lujnan Another reference:

• https://github.com/libusb/libusb/issues/182 https://marc.info/?l=libusb-devel&m=147808669913635&w=2

From the answer above by @jwrdegoede, I think the recommendation is not to mix synchronous and asynchronous APIs in multithreaded application.

++++++++++++++++++++++++++++++++++++++++++++++++++ List: libusb-devel Subject: Re: [libusb] Wake up synchronous calls on close? From: Hans de Goede <hdegoede () redhat ! com> Date: 2016-11-02 11:37:42

Hi,

On 02-11-16 11:56, Romain Vimont wrote:

Hi,

I observed that closing a device handle does not wake up any synchronous call blocking on it.

I just wrote a sample to reproduce this: https://github.com/rom1v/libusb-sample

Is it the expected behavior?

Yes, your supposed to clean up any outstanding transfers before closing. If you use synchronous calls, then I would expect your apps to be single threaded, use timeouts to detect errors, and close after timeout. If you've a multi-threaded app you really should not be using the synchronous API.

Regards,

Hans

[lujnan]

like the camera and IMU application，mix the sync and async API is a nice programming pattern.

[mcuee]

like the camera and IMU application，mix the sync and async API is a nice programming pattern.

I understand. It is just you need to be very careful when mixing the sync and async API in multithreaded application.

[lujnan]

My issue is the same as #1077， the #1267 pr does not solve my problem.

[lujnan]

the ioctl(hpriv->fd, IOCTL_USBFS_REAPURBNDELAY, &urb) function will take out an urb， after that, whatever whether it is locked or not, if it is taken out in a different thread, it will cause disorder.

[lujnan]

This issue is easy to appear on embedded devices such as mobile phones, and it is not easy to reproduce on PCs. It may be that the USB controller or CPU on the PC is more powerful.

[mcuee]

@lujnan I do not think you can conclude your issue is the same as #https://github.com/libusb/libusb/issues/1077 yet. It is better not to mix the two before confirmation as of now.

For one thing, have you reproduce the issue under Windows or macOS? For Windows, you can try on slow machine (eg: mini PC running low power Intel processor).

[mcuee]

@lujnan

Any updates on this topic? Have you tried with Windows or macOS?

I tend to believe this is most likely an application issue and not libusb issue.

[lujnan]

Yes, It's a libusb issue, The current architecture cannot guarantee that it will work properly in application or third-party libraries

[mcuee]

Yes, It's a libusb issue, The current architecture cannot guarantee that it will work properly in application or third-party libraries

You will need to provide sample codes and debug log to demonstrate that it is a libusb library issue.