C++ --> Java multi threading with director

Hello!

I have created a callback in C++ and it is beautifully wrapped by the
director feature, and it works very well.

From my C++ library, this callback can be called on different native worker
threads.  The call seems to work fine in my simple unit testing however I
noticed this strange behaviour.

I have printed out the thread ID whilst in a java instance of the
callback.  Every time it is called it looks like it is getting a new thread
ID, however I know that there is only one worker thread calling it.

The worker thread is not the main thread that this junit test case below is
created on

Here's some details:

Development environment

OS

Mac OS Big Sur

swig

SWIG Version 4.0.2

Compiled with clang++ [x86_64-apple-darwin20.1.0]

Configured options: +pcre

java

java version "11.0.11" 2021-04-20 LTS

Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)

Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)

compiler

Apple clang version 12.0.0 (clang-1200.0.32.29)

Target: x86_64-apple-darwin20.6.0

Thread model: posix

InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


*Here's the callback class header*

template <class T> class IBioSignalProcessorCallback {
public:
  virtual ~IBioSignalProcessorCallback() {}
  virtual void process_data_point(IInputSignal<T> *signal,
                                  IBioSignalProcessor<T> *processor,
                                  const T data[], int64_t timeStamp) = 0;
  virtual void process_state_message(IStateMessage *msg) = 0;
};


*Here's from the swig implementation file*

%feature("director") IBioSignalProcessorCallback;

%include "include/IBioSignalProcessorCallback.h"

%template (FloatBioSignalProcessorCallback) IBioSignalProcessorCallback<float>;
typedef IBioSignalProcessorCallback<float> FloatBioSignalProcessorCallback;


*Here's the java code I used in my junit test suite*

        class AccCallback extends FloatBioSignalProcessorCallback {
            public AccCallback() {
                super();
            }
            @Override
            public void process_state_message(IStateMessage msg) {
                System.out.println("State message AccCallback : " +
msg.get_message_key() + " thread ID "+ Thread.currentThread().getId());
            }
            @Override
            public void process_data_point(FloatInputSignal signal,
FloatBioSignalProcessor processor, SWIGTYPE_p_float data, long timeStamp) {
            }
        }


Here's the results from the java test suite

State message AccCallback : HR_SIGNAL thread ID 12
State message AccCallback : HR_SIGNAL thread ID 13
State message AccCallback : HR_SIGNAL thread ID 14
State message AccCallback : HR_SIGNAL thread ID 15
State message AccCallback : HR_SIGNAL thread ID 16
State message AccCallback : HR_SIGNAL thread ID 17
State message AccCallback : HR_SIGNAL thread ID 18
State message AccCallback : HR_SIGNAL thread ID 19
State message AccCallback : HR_SIGNAL thread ID 20
State message AccCallback : HR_SIGNAL thread ID 21
State message AccCallback : HR_SIGNAL thread ID 22
State message AccCallback : HR_SIGNAL thread ID 23

The callback works beautifully but this strange thread behaviour is
troubling, any ideas or thoughts on this?  Should I simply not worry about
the many threads that are created?  (it looks like they are destroyed after
the call because they aren't lingering).

I worry about this because at some point I will have an audio stream thread
and the worry is about latency and overhead on the stream calls.

When I do native callbacks from the instantiating thread to the
process_data_point function it works as expected and the thread id is
always the same (the same thread that the wrapped class was created on).
My initial thoughts are that the Director locks in the JNIEnv on the thread
that creates it.  When the call from the worker thread comes in it looks
like maybe it is switching it over to a new thread?


Kind Regards,

PJ

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user