#3 excessive thread creation - one for each image
posted by pdm9 in the forum:
Hi Ken,
I'm using the lti-civil library as a lightweight alternative to JMF (and FMJ)
as I only require a video capture facility, and it's working really well. However
I was debugging an (unrelated to lti-civil) thread synchronisation problem in
Eclipse when I noticed that I had a lot of very short-lived threads being created.
On further investigation it seems that a new thread is spawned for each call
to onNewImage(...) for my CaptureObserver - using a CaptureObserver with the
following callback
public void onNewImage(CaptureStream sender, Image image) {
System.out.println(Thread.currentThread().getName() + " onNewImage");
}
produces the following output
Thread-4 onNewImage
Thread-5 onNewImage
Thread-6 onNewImage
Thread-7 onNewImage
Thread-8 onNewImage
Thread-9 onNewImage
etc...
Is there a good reason why the callback for each frame is invoked in a separate
thread? Surely the capture of frames from the camera at regular intervals is
inherently synchronous? I'm seeing frequent pauses in my application that could
well be the result of excessive garbage collection, and even occasional
OutOfMemoryErrors when the application has been running for an extended period.
Thanks in advance
Paul
Logged In: YES
user_id=911347
Originator: YES
My response:
Interesting.
I assume you are running the windows version, if not, let me know.
Anyway, in the native code JNICaptureObserver.cpp
in
void JNICaptureObserver::onNewImage(CaptureStream *sender, Image *image)
we have
res = jvm->AttachCurrentThread((void**)&pEnv, NULL);
This is because the capturing is happening in a native background thread. I'm pretty sure that this is the same native thread every time. However, maybe, with each image, since we call AttachCurrentThread, maybe that creates a new java thread to bind to the same native thread over and over.
I honestly don't know much about AttachCurrentThread, although I did write that part of the code. It is needed anytime a native background thread wants to callback to Java. I wonder if there is some way to either only call AttachCurrentThread once, or have AttachCurrentThread always bind to the same Java thread, when the native thread hasn't changed. I agree that the thread creation you are seeing is excessive.
The threads themselves are getting disposed and garbage collected, aren't they?
This still happens on Windows XP, SP3, Java 6: Eclipse shows rapid creation/deletion of threads. After killing the debug run, WordPad refused to open and Firefox (which had nothing to do with the code) crashed. These two programs had previously worked fine for years. My guess is that available handles were exhausted.