• Post Reply Bookmark Topic Watch Topic
  • New Topic

JNI and Thread DeadLocking Problem

 
Sam Doder
Ranch Hand
Posts: 204
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have asked everywhere but I cann't figure this out.
When I run the native method in a thread it doesn't work.
It stops right at the capGrabFrame(hwndcap) ;

Here is the JNI method that is the problem.




For those who don't know the function's capGrabFrame and capFileSaveDIB
are from the c++ vfw.h .

I believe it is deadlocking some how.
I have tried env->MonitorEnter(obj) , ... env->MonitorExit(obj) but that didn't do much. I even tried creating a global Reference to the class but
that didn't work either. I even used native exception handleing but no error occured.
Vfw.h uses messaging services like sendMessage.... could that be the reason
for deadlocking?

Anyway I just want to know how I can get this method to work in a thread.
Not an expert on JNI Thread Problems so I could have made a mistake some where.

The native method works when I use it in infinite while loop.
Unfortunately for me I need it in a thread.

I will kneel before the person that solves this one.
Thanks for any help.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you say it goes wrong when you run in a thread, that doesn't really make sense, because you are always running in a thread. Do you mean that it goes wrong when you run it in a thread other than the main thread? Or maybe a thread other than the Swing event thread? In which thread does it work OK?

There are no Java threading operations in your posted code. If it hangs at the point you highlight, then it's not a Java thread deadlock issue, because nothing would be trying to lock Java monitors at that point. The capXXX() functions are in Video For Windows API, which clearly doesn't know anything about Java.

What are the threading restrictions of the Video For Windows API? Have you found API documentation and looked it up? Perhaps a particular process is restricted to certain threads.

Where did you get this hwndcap handle from? Perhaps you got it in a different thread. Perhaps the Video For Windows API does not allow handles obtained in one thread to be used in another thread? Just guessing.
 
Sam Doder
Ranch Hand
Posts: 204
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I don't think it is the java code that is deadlocking.
I am going to search around more on the VFW.

To answer your question The class that I call the native method in
extends JPanel and implements Runnable.
Then in the run method I have an infinite while loop that calls captureFrame() and then the paint method.
In paint I draw the bmp image by opening the file.

This class gets add to the contentPane of my JFrame class.

I have read that some messaging functions like sendMessage can lead to deadlocking. And I believe that the VFW uses send/post messaging services.

Their is another native method I use to initialize the capture window
which is where I got my handle hwndcap. hwndcap is a global variable.
Anyway that isn't the problem.
The problem is how to stop the capGrabFrame(hwndcap) from deadlocking?


Their is another way I am considering.
But I need to know how to get a Handle to a Swing Component such as JPanel.
Then I can just use this handle for the captureWindows parent instead of saving to a file and reading from a file.

Anyway is their any other way to get a handle to a swing component other then using a peer class. Because I have heard that the peer classes shouldn't be used because they may not be supported on new versions of java. I would like this program to run on all versions 1.4.2 onward.

Maybe the answer is using jawt.h to get a handle.

Pleasing explain if you know of any other ways to get a handle to a java GUI object.

Thanks for your post
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!