Update libusb 1.0.9 to libusbx 1.0.16

Update libusb 1.0.9 to libusbx 1.0.16.
libusb 1.0.9 has serious deadlock bugs on Windows. libusbx is the rapid-development version of libusb and will be eventually merged into libusb.

BUG=223817
R=pfeldman@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=212597

[pfeldman, 2013-07-19 06:47:23]

I noticed that you are applying this on top of not-yet-committed
https://codereview.chromium.org/18593002. I think this one should go first and
you should remove the interrupt.* from here. Otherwise, looks good. I'll test
adb scenarios on top of this new code today.

Btw, why would you need interrupt at all? Given that it is followed with Join of
the IO-type thread, Stop is going to be blocking and can't be called on Browser
UI thread anyways. So I guess, it should be resolved in a different manner. I
thought you mentioned that you were going to route things via FILE thread. That
way, you would Join event thread from within FILE thread and gracefully shutdown
the context. That's how we handle it in other places
(https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/de...)

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
File third_party/libusb/libusb.gyp (left):

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
third_party/libusb/libusb.gyp:19: 'src/libusb/interrupt.c',
There is no interrupt neither in libusb 1.0.9 not in libusbx 1.0.16

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
File third_party/libusb/windows-build.patch (right):

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
third_party/libusb/windows-build.patch:27: diff --git
a/libusb/os/threads_posix.c b/libusb/os/threads_posix.c
nit: this is not related to windows, so the patch name should no longer include
"windows"

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
third_party/libusb/windows-build.patch:51:
+			usbi_mutex_unlock(&ctx->open_devs_lock);
Great!

[pfeldman, 2013-07-19 08:32:15]

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
File third_party/libusb/libusb.gyp (left):

https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
third_party/libusb/libusb.gyp:19: 'src/libusb/interrupt.c',
Oh, I now see that you've already landed it. lgtm then.

[Bei Zhang, 2013-07-19 17:01:22]

On 2013/07/19 06:47:23, pfeldman wrote:
> I noticed that you are applying this on top of not-yet-committed
> https://codereview.chromium.org/18593002. I think this one should go first and
> you should remove the interrupt.* from here. Otherwise, looks good. I'll test
> adb scenarios on top of this new code today.
> 
> Btw, why would you need interrupt at all? Given that it is followed with Join
of
> the IO-type thread, Stop is going to be blocking and can't be called on
Browser
> UI thread anyways. So I guess, it should be resolved in a different manner. I
> thought you mentioned that you were going to route things via FILE thread.
That
> way, you would Join event thread from within FILE thread and gracefully
shutdown
> the context. That's how we handle it in other places
>
(https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/de...)

Yes, I'm joining the thread (but on UI thread) before shutdown, but the
libusb_handle_events function will block for a minute.

This interrupt function will interrupt libusb_handle_events immediately. With a
proper set memory barrier, it can exit gracefully.

>
https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
> File third_party/libusb/libusb.gyp (left):
> 
>
https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/libusb...
> third_party/libusb/libusb.gyp:19: 'src/libusb/interrupt.c',
> There is no interrupt neither in libusb 1.0.9 not in libusbx 1.0.16
> 
>
https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
> File third_party/libusb/windows-build.patch (right):
> 
>
https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
> third_party/libusb/windows-build.patch:27: diff --git
> a/libusb/os/threads_posix.c b/libusb/os/threads_posix.c
> nit: this is not related to windows, so the patch name should no longer
include
> "windows"
> 
>
https://codereview.chromium.org/19713005/diff/34011/third_party/libusb/window...
> third_party/libusb/windows-build.patch:51:
> +			usbi_mutex_unlock(&ctx->open_devs_lock);
> Great!

[scheib, 2013-07-19 17:09:12]

Committed patchset #1 manually as r212597.

[pfeldman, 2013-07-19 18:56:08]

> Yes, I'm joining the thread (but on UI thread) before shutdown, but the
libusb_handle_events function will block for a minute.

I thought UsbService was per-profile, so you are doing it on switching profiles
too. And you can't join blocking threads on UI thread anyways. You event
dispatching thread should be of type IO and the following check should fail:
https://code.google.com/p/chromium/codesearch#chromium/src/base/threading/pla....
You might have not marked your thread as IO, but it still is logically. I agree
that waiting for a minute is not an option thought, so we need to do both:
interrupt and graceful join.