On May 15, 10:00 pm, Jackson Fan <xy...@motorola.com> wrote: > 1. In Java code, modify the API to be as 2 steps: one immediate native > call, follows with waiting for notification; > 2. In JNI code, create a sepearate native thread for your heavy > function and directly return to Java; > 3. In the created native thread code, notify Java once finishes > execution; > 4. Java gets the notification and wakes up a waiting object or to post > a message; > 5. This way Java can offer more API patterns, with async call, sync > call or sync call with timeout threshold;
You're also creating a kernel-visible thread, allocating a Thread object, and doing lots of other housekeeping every time you make that native call. If this is something you plan to call often, you're much better off with a single persistent "worker" thread. Whether you hand control to that thread from Java code or native code is up to you -- you can leave your Java code looking the way you describe but use a persistent thread under the hood. It's probably best to keep the thread-hopping visible at the Java level though, since it'll make your application easier to debug. You really want to be able to see as much as possible from the Java debugger. Keep the native code as straightforward as possible. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to android-framework@googlegroups.com To unsubscribe from this group, send email to android-framework+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
