hello

i've another problem, and i think it must be somehow solved in
mozilla/liveconnect:

we use the liveconnect enabled spidermonkey engine. at startup of the
software we initialize the jvm environment by calling
JSJ_ConnectToJavaVM() and executing JNI_CreateJavaVM()  in the createvm
callback. so far so good.

also we have a pool with (initialized) js context's, and everytime the
application needs a context, we return an unused context out of the pool
and do also the liveconnect initialisation.
the liveconnect initialisation does the following:
- we attach the current thread with a call to
JSJ_AttachCurrentThreadToJava()
- we create a structure which holds the thread specific JSContext,
JSJavaThreadState and JNIEnv and add it to a map with the thread id as
key

now initialisation is done, and when we must return for example in
mapJSJThreadToJSContext the js context for a thread, we make a lookup in
the map and return the context out of the structure.

now, here the problems begins:
- first, assume we have more than one js context per thread, the
initialisation is done more than once for a thread (means that we call
the JNI function AttachCurrentThread multiple times for the same thread.
i assume the jvm doesn't really like me for that.:)
ok, that can be solved by checking if the current thread already exists
and do the initialization only if we cant find the current thread id in
the map. but one problem persists:
- we have multiple js context's for one thread and must return the right
one if e.g java calls back to javascript. in the current implementation
we handle it by having a stack, returning always the top stack context
and hoping that everytime another context for the same thread is
requested, we dont use the first context until the second is released
again. imho we need another criteria to decide which context will be the
right, but what can we use for this? What uses mozilla to achieve this?

thanks for any help, suggestions and tips in advance!

greets,

michael schneider
software engineer

obtree technologies inc.



Reply via email to