Blocked Threads with JNI loop
Patrick Tullmann
kaffe@rufus.w3.org
Thu, 20 Jul 2000 13:30:07 -0600
> I tried it with the Call to Thread.sleep(). Blocking ends!
Glad that fixed it.
> But there is a Call to a select() statement which is blocking for
> 1 second. In this time the other threads are blocked again.
Is the select doing anything more than a timeout? If there are any
valid file descriptors in the select(), then the you really need to
re-write the code to use the VM's file interfaces. JNI might provide
such an interface.
The KaffeVM (and, I would guess, all other VMs) assumes it has
complete control over the threading (locking, blocking, switching).
It also assumes that it controls memory allocations, file accesses,
network access, etc. Anytime you do non-trivial operations in your C
code attached to a JVM you will probably step on the JVM's toes.
Sometimes this may not matter (e.g., you just block the whole VM while
you do a blocking read on a file descriptor), but you can mess things
up (malloc and threading especially).
> But where is the difference to the sun jvm, is it the threading
> system? Or the JNI Implementation?
I don't know enough about JNI to say, but I belive Kaffe's JNI
implementation is up to speed. Note that select() and sleep() are not
part of JNI. (Right?)
-Pat
----- ----- ---- --- --- -- - - - - -
Pat Tullmann tullmann@cs.utah.edu
Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere