Is there a way to force a native thread to exit through JNI?

views:

answers:

Is there a way to force a native thread to exit through JNI?

I have a program that's using the FFMPEG binary libraries via JNI. There is a call to open a URL which is blocking in native code, and I need to allow the user to manually cancel this connection. Sometimes Thread.interrupt() works just like it's supposed to (if the url I'm connecting to is "udp://{whatever}"). If my URL is "rtp://{whatever}", Thread.interrupt() doesn't appear to be honored by the native thread. Thread.kill() doesn't even seem to do it (and is generally frowned on anyhow).

Does anyone know a different way to interrupt or kill a native thread through JNI?

The native code can regularly check the thread to see if it's interrupted, just as Java code does.

Another approach is operating-system-specific, but you can send you thread a signal and that signal can set a flag - this may be more straightforward for the JNI-side to check.

All thread-stopping is cooperative - you tell the thread to stop by setting a flag (via Thread.interrupt() or a flag set in a signal handler - and the thread code checks this often.

Will 2010-06-10 12:32:24

I'm using FFMPEG as a native library, and I'd REALLY like to avoid changing the native side if at all possible - if it's unchanged I can just use the pre-built binaries rather than having to recompile it myself for every target platform.I'm a bit of a JNI newbie, is there a way to send a signal to a thread from the Java side (other than interrupt), in hopes that there's something that the native side IS actually checking for?

2010-06-10 12:51:38

you can't litter your FFMPEG code with checks but you can check in the JNI code that calls the avcodec avformat bits per frame?

Will 2010-06-10 13:52:24

If I was in the frame processing loop, I could, but my thread is blocking trying to open the URL in the first place (I'm worried about the case where a user has mistyped the URL, and wants to free up the resources because they're NEVER going to receive any data there). It appears to be the call to av_open_input_file in libavformat/utils.c that's blocking and not being interrupted properly.

2010-06-10 20:22:34

+2 A:

Take a look at how Xuggle does this (a JNI wapper to FFmpeg). Everytime FFmpeg calls it's interrupt callback, Xuggler calls into Java to see if the thread was interrupted, and if so, returns true.

Xuggle 2010-06-14 15:27:29

Lol! I'm actually already using Xuggle. This question is effectively a duplicate of a post I eventually made on the Xuggle forums: http://groups.google.com/group/xuggler-users/browse_thread/thread/30d73c1b1a6bb95cThanks, though!

2010-06-15 11:28:50

ansaurus

tags:

views:

answers:

Is there a way to force a native thread to exit through JNI?

related questions