This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]