Re: [OT] JNI + Threads

Josef Henryson wrote:

1. A component I need is implemented to be thread-safe and handle

sessions. This means that the component itself does not manage

threads but it saves session data locally with reference to the

current thread.

In essence, it appears to be written to require a thread/session binding.

Too bad, because separating threads from sessions would be a lot easier to

deal with, even in a C++ context.

2. I call this component which is a JNI-library (C++ & JNI files)

from my Java code, e.g. a web application. I want to be sure that

when I call the JNI library from the web application, the session

data stored in the library is always associated with the same user

thread. For example, the results from a second call should be based

on saved data from the first call.

That forced correlation to a thread is going to be a huge pain.  To work

around it, you're going to have to use Threads to implement subroutines.

Besides being hideously ugly and prone to errors, this may adversely affect

latency, though it's probably the least of your concerns (correctness

trumps speed).

What you'll have to do is create a separate dedicated Thread whose sole

purpose is to make calls into the JNI library, and thereby retain the

required binding between a thread and a session.  It should probably be a

Thread subclass, with one Java method for each action of interest to your

API.  What each method has to do is:

  1. store the method's args in instance fields.

  2. notify the waiting Thread to take an action.

  3. wait for the Thread to return.

  4. collect return values from instance fields.

  5. return from the method.

  6. do all the above Thread-safely.

The dedicated Thread sits in a loop:

  1. wait() indefinitely on an object.

  2. awaken and decode an action-selector field.

  3. pass other fields as args to native method.

  4. store return values into fields.

  5. notify() the other Thread that's waiting for results.

  6. do all the above Thread-safely.

This is basically a grotesquely deformed producer-consumer queue of zero

length.  It gets even uglier if there are lots of methods and you have a

giant switch statement to decode the action-selector.  I'm feeling ill just

thinking about coding it.

The people developing the component tells me this is the way sessions

should be handled and that the Thread calling the library is linked

to the session data. They are C++ developers however and I'm not

convinced that this will work with Java in the same way as with C++.

There is no "should" here.  They made a design choice.  It may have been

intentional or unwitting, but it was still a choice.  It may have been a

convenient choice for certain C++ situations, but I can easily imagine a

C++ session that wasn't tied to a single thread, so it still seems like a

needlessly limiting design choice to me.

If there was just a session-ptr to a struct, or an arbitrary opaque ID, and

you were given the option of where to store it instead of requiring it to

be a thread-local variable, then that seems much more open-ended and

practical to me.

If I were you, I'd be looking for another library that didn't force me to

abuse threads as subroutine control-locus stacks.

  -- GG

 _______________________________________________

Do not post admin requests to the list. They will be ignored.

Java-dev mailing list      (email@hidden)

Help/Unsubscribe/Update your Subscription:

http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden