How to trigger JNI blocking?

I’m making some JNI calls from C to Java. The Java call normally does its
thing and returns a result. However, one of my Java calls takes over and
displays overlaid UI that I want to cause the C code to block. I do get an
onPause log message and blocking eventually, but the C code is not blocked
right away. The result is that some C code that is dependent on the UI
actions gets executed before the user is finished interacting with the UI.

Here’s some C-side pseudocode:
jni_show_password_UI();
// I want to block here until the UI is done.
// If I don’t, then jni_did_enter_password() would always be false.
bool entered_password = jni_did_enter_password();
if(entered_password)

Is there a way to trigger the blocking intentionally so the C code will
onPause immediately? I’ve tried calling SDL_PumpEvents() because I thought
that’s where the blocking happens, but it didn’t have any effect.

Jonny D

2013/8/23 Jonathan Dearborn

I’m making some JNI calls from C to Java. The Java call normally does its
thing and returns a result. However, one of my Java calls takes over and
displays overlaid UI that I want to cause the C code to block. I do get an
onPause log message and blocking eventually, but the C code is not blocked
right away. The result is that some C code that is dependent on the UI
actions gets executed before the user is finished interacting with the UI.

Here’s some C-side pseudocode:
jni_show_password_UI();
// I want to block here until the UI is done.
// If I don’t, then jni_did_enter_password() would always be false.
bool entered_password = jni_did_enter_password();
if(entered_password)

Is there a way to trigger the blocking intentionally so the C code will
onPause immediately? I’ve tried calling SDL_PumpEvents() because I thought
that’s where the blocking happens, but it didn’t have any effect.

Jonny D

The problem is that SDL on Android operates with two threads, the Java one
and the “native” one where your app loop lives. Signaling between those is
tricky, and the loop can’t stop right away in the general case because
certain messages need to arrive to the app before it blocks.

The easiest solution I can see from your pseudo code is to poll in an
infinite loop for jni_did_enter_password after calling jni_show_password_UI.

Another option, more elegant but also more prone to unwanted lock ups, if
you give yourself access to Android_ResumeSem / Android_PauseSem you can
imitate what Android_PumpEvents does right after calling
jni_show_password_UI, minus the “waiting for certain events to finish
processing” part.–
Gabriel.

Yeah, the infinite loop workaround is good enough and simple enough. It
means I need a state identifier for “user is still entering password”, but
since it seems that Java integer operations are atomic, the code is pretty
easy.

Thanks for confirming what I was thinking about with this problem and for
the suggestions. :slight_smile:

Jonny DOn Fri, Aug 23, 2013 at 3:34 PM, Gabriel Jacobo wrote:

2013/8/23 Jonathan Dearborn <@Jonathan_Dearborn>

I’m making some JNI calls from C to Java. The Java call normally does
its thing and returns a result. However, one of my Java calls takes over
and displays overlaid UI that I want to cause the C code to block. I do
get an onPause log message and blocking eventually, but the C code is not
blocked right away. The result is that some C code that is dependent on
the UI actions gets executed before the user is finished interacting with
the UI.

Here’s some C-side pseudocode:
jni_show_password_UI();
// I want to block here until the UI is done.
// If I don’t, then jni_did_enter_password() would always be false.
bool entered_password = jni_did_enter_password();
if(entered_password)

Is there a way to trigger the blocking intentionally so the C code will
onPause immediately? I’ve tried calling SDL_PumpEvents() because I thought
that’s where the blocking happens, but it didn’t have any effect.

Jonny D

The problem is that SDL on Android operates with two threads, the Java one
and the “native” one where your app loop lives. Signaling between those is
tricky, and the loop can’t stop right away in the general case because
certain messages need to arrive to the app before it blocks.

The easiest solution I can see from your pseudo code is to poll in an
infinite loop for jni_did_enter_password after calling jni_show_password_UI.

Another option, more elegant but also more prone to unwanted lock ups, if
you give yourself access to Android_ResumeSem / Android_PauseSem you can
imitate what Android_PumpEvents does right after calling
jni_show_password_UI, minus the “waiting for certain events to finish
processing” part.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org