Android SurfaceTextureHelper: Don't wait for pending frames in disconnect()

Android SurfaceTextureHelper: Don't wait for pending frames in disconnect()

This CL also makes some small non-functional changes in ThreadUtils and EglBase to support SurfaceTextures and SurfaceTextureHelper.

BUG=webrtc:4993
R=hbos@webrtc.org

Committed: https://crrev.com/1ab271c1c49191e04e3ac9516e6d92cde739a954
Cr-Commit-Position: refs/heads/master@{#10085}

[magjed_webrtc, 2015-09-25 13:17:03]

magjed@webrtc.org changed reviewers:
+ hbos@webrtc.org

[magjed_webrtc, 2015-09-25 13:17:13]

hbos - Please take a look.

[hbos, 2015-09-28 08:43:02]

lgtm as far as the code goes, but I'm curious, why would you or would you not
want release() to wait for the frames?

https://codereview.webrtc.org/1368093003/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/ThreadUtils.java (right):

https://codereview.webrtc.org/1368093003/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/ThreadUtils.java:44: public static void
executeUninterruptibly(BlockingOperation operation) {
super-nit: Considering this can legitimately be used from the outside for
arbitrary blocking operations (you've made it public, which is a good thing) I
would not refer to it as simply a "helper function" but rather a utility method
of the same class as joinUninterruptibly and awaitUninterruptibly.
You could also add a comment to BlockingOperation ifyawanna.

[magjed_webrtc, 2015-09-28 09:05:36]

The primary reason for not waiting for returnTextureFrame() in disconnect() is
that you can easily get into a deadlock that way. Also, not waiting for
returnTextureFrame() will make e.g. decoder reconfigurations slightly faster.

https://codereview.webrtc.org/1368093003/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/ThreadUtils.java (right):

https://codereview.webrtc.org/1368093003/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/ThreadUtils.java:44: public static void
executeUninterruptibly(BlockingOperation operation) {
On 2015/09/28 08:43:02, hbos wrote:
> super-nit: Considering this can legitimately be used from the outside for
> arbitrary blocking operations (you've made it public, which is a good thing) I
> would not refer to it as simply a "helper function" but rather a utility
method
> of the same class as joinUninterruptibly and awaitUninterruptibly.
> You could also add a comment to BlockingOperation ifyawanna.

Done.

[magjed_webrtc, 2015-09-28 09:06:40]

Committed patchset #2 (id:20001) manually as
1ab271c1c49191e04e3ac9516e6d92cde739a954 (presubmit successful).

[commit-bot: I haz the power, 2015-09-28 09:06:43]

Patchset 2 (id:??) landed as
https://crrev.com/1ab271c1c49191e04e3ac9516e6d92cde739a954
Cr-Commit-Position: refs/heads/master@{#10085}