This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: CNI namespace
Cedric Berger <cedric@wireless-networks.com> writes:
> class NativeQueue {
> native void send(Packet p);
> native Packet receive();
> }
> class ReceiveThread(NativeQueue q) {
> public void run() {
> for(;;) {
> Packet p = q.receive();
> switch(p.getQuery()) {
> ...
> }
> }
> }
> }
> public stratic void main()
> {
> NativeQueue q = new NativeQueue();
> (new NativeThread(q)).start();
> Packet p = new Packet(36);
> nativeQueue.enqueue(p);
> ...
> }
>
> What will appends with the Packet class when it's
> "outside" the VM? how will a native thread call it's
> setResponse() method? will there be more than
> one wrapper around Packet?
>
> Cedric
>
>
>
>
>
>
> Paul Fisher wrote:
>
> > Cedric Berger <cedric@wireless-networks.com> writes:
> >
> > > You cannot store JNIEnv in an object, because this pointer is
> > > different for each thread. So if two threads access the same object,
> > > CRASH.
> >
> > The object, or rather more of a proxy object, is created when the
> > foreign VM calls a JNI function. The proxy object exists until the
> > JNI function returns, which is always in the context of a single
> > thread. So each JNI invocation creates a new proxy object for `this',
> > along with any other proxy objects that become necessary as execution
> > continues.
> >
> > > When I deal with native functions and JNI, I define a function that
> > > looks like:
> >
> > That could be used as an alternative to storing each JNIEnv as thread
> > local data, but we need something that will work with 1.1 VMs.