Hi,
I've done as you suggested, and have confirmed using a C wrapper that the callback does indeed use the same thread every time, despite using a new Java Thread object for each invocation.
But I still have a problem with this: every time the callback is called, a new Java Thread object is created. All the Thread constructors call Thread.init which means that this Java thread is being fully initialised even if it is only being used as a kind of placeholder for the native thread.
Testing on my (high spec) server shows that creating a new Java Thread object takes around 10 microseconds which is a big overhead for my realtime system.
(I allowed for hotspot warmup in my testing.)
Avoiding this Thread object construction would therefore have a significant impact on the performance of callbacks from C->Java.
Is there any way to reuse an existing Java thread rather than creating a new one?
Thanks.
-----Original Message-----
From: "Timothy Wall" [twalljava-***@public.gmane.org]
Date: 28/03/2010 13:06
To: users-qzFMjIOsJ+***@public.gmane.org
Subject: Re: [jna-users] callback threads - help needed
Post by Ryan Duffy[Sorry if this is a double post - I've waited 12 hours since originally sending it but it hasn't shown up yet...]
I'm feeding realtime data from a C++ library into my Java application via a callback called from C++ into a Java method.
As high performance is critical, I want to ensure that I have full control of the threadpool that is used on the Java side (which I can do easily enough once I have control in the callback method). What I want to ensure is that there are not threads being created each time the callback is called by C++, so that I am using a single thread to make the calls from C++ and I want the same single thread to deal with them on the Java side, so I can then decide precisely what happens at point within my Java application.
Reading your original response again, you seem to be suggesting that it is a single thread running on the Java side that appears to be multiple threads due to being mapped to new Thread objects for each invocation of my Java callback. Is that what you meant? If so, why does my Java debugger also think these are independent threads being created for each callback (so when I pause my app there are multiple threads still in existance which haven't yet been GC'd after terminating?
Your Java debugger can't tell the difference between a wrapped thread and a "real" one. Suggest it as an improvement to your debugger vendor.
If you want to check for certain, make a C method that identifies the current thread, and call it from your java callback. You should get the same value back every time.
Post by Ryan DuffyIf, as it appears, there is indeed a new thread created for each callback, how do I prevent this from happening?
(Sorry, I'm a noob with JNA and have only been experimenting with it for a couple of days - I've been unable to find any method of threadpools in the docs).
Also, I seem to see memory usage increasing rapidly as the callbacks happen. I'm using primitives and pass-by-value from C++ so I can't see why I'd need to explicitly free any memory after the callback finishes, but perhaps I've missed something.
There's a bit of bookkeeping when the callback is first called, but most of the information is cached and so shouldn't require the overhead on every call. However, I've not done much performance analysis on callbacks, so I may be wrong.
Post by Ryan DuffyThanks.
-----Original Message-----
Date: 27/03/2010 20:56
Subject: Re: [jna-users] callback threads - help needed
What is the behavior you need and why?
Post by Ryan DuffyHi,
Thanks for the rapid response.
Your explanation is certainly consistent with my observation, so my question is: how do I map the native thread making the callback to a single Java thread so I get the behaviour I need?
Thanks.
-----Original Message-----
Date: 27/03/2010 02:38
Subject: Re: [jna-users] callback threads - help needed
If the native thread making the callback is not already mapped to a Java thread, it gets mapped to a new Java thread object for the duration of the callback. No extra native thread is created, but you can see why you'd see a new Java Thread object on each call. I would imagine the object gets GC'd after it is unmapped.
Post by Ryan DuffyHi,
I've written a callback method in Java that is called from a C++ library (via an extern C wrapper that registers my Java method with the callback).
This all works fine, except that every call made to my callback is running in a new thread. I've printed the thread id from the C++ side where the call to the Java function is made and that always has the same id - so I'm only using one thread on the C++ side.
This leads me to assume that JNA is creating a new thread every time the callback function is called. This seems highly inefficient and certainly isn't what I want happening.
I'm using the current stable JNA (3.2.4) with the direct mapping interface.
Can anyone shed any light on this? Ideally I'd like to be able to define my own threadpool that would be used for the callbacks, but failing that I'd like a single thread to be used so I can manage the threading explicitly myself.
Thanks in advance for your help!
Dus.
Wanna lose weight? Weight Loss Programs that work. Click here.
Diet Help
Click Here For More Information
---------------------------------------------------------------------
Don't stay in a roach motel. Click here to find great deals on hotels.
Hotel
Click Here For More Information
---------------------------------------------------------------------
Click here to light up your life with a love spell!
Love Spell
Click Here For More Information
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe-qzFMjIOsJ+***@public.gmane.org
For additional commands, e-mail: users-help-qzFMjIOsJ+***@public.gmane.org
------------------------------------------------------------
Best Weight Loss Program - Click Here!
Weight Loss Program
http://tagline.excite.com/c?cp=WkGqMfWfCQPfkkjKgp5xIAAAKZTuEcuxkFLkCweqwMoGDCPuAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAEUkL2pRg=