Thread: [Sablevm-developer] Thread.interrupted() - mess? (screenshot!)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all, it'll be a longer email...

I have a working implementation of interrupted(). I must say it's not
the best documented part of Java platform, so between the moment
I started a few days ago (and in fact coded it) and now, I had some
discussions (notably with Tom Tromey and Mark Wielaard), I also looked
at how JCVM and Kaffe handle these things... And I'll be rewriting it
surely. The question is: how should it work?


Doubts:

* to set a flag in interrupt handler or not

Reasonably simplistic implementation would just check for EINTR, set
the flag in env->thread and throw the exception. But EINTR may also
happen if nobody called interrupt() and AFAIK in many such cases we
should get back to the syscal which was interrupted. On the contrary,
what JCVM does seems a bit dangerous, like getting exclusive VM lock
in signal handler to set flags... Apparently it can be done even
differently - Tom Tromey told me (I haven't looked at the code) GCJ
signal handler for interrupt() does nothing.

So, my conclusion was that best I can do is set
env->thread.interrupted = JNI_TRUE;
env->thread.interrupted_thrown = JNI_FALSE;
in signal handler, w/o any atomicity. I see no reason as we won't get
two same signals at the same time and even if - all they would do would
be to also set the same flags. These flags aren't changed by any other
thread and _the_ thread is stopped while we execute signal handler for
it.

* when a thread is considered to be interrupted?

Is it: when some other thread sends interrupt() or when the thread
actually notices that and throwns the exception? I think rather the
latter, and so should isInterrupted() act (checking both flags).

* what does it mean that a thread notices it's been interrupt()ed?

Even if I have a flag set from interrupt handler and I also check EINTR,
it still may happen, that loooong ago some other thrad called
interrupt() which set the flag but didn't interrupt any syscall, then
after some undefined time I get into completly another method in a
program which happened to call ex. wait() and wait gets EINTR (ex.
pthread_cond_wait() can spuriously wake up! btw. JCVM implementation is
superior here).

So we match the EINTR with set-up-long-ago interrupted flag and we
throw InterruptedExcpetion instead of getting back to *_cond_wait()!

Is that expected behavior?
if not - where should I reset interrupted flag? on the entry to
the wait() function?

* do we need to take into account thread status? Ex. not send the signal
if thread is in SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED?
(if I send the signal the syscall will be interrupted already).

* I wonder how much atomicity we need here. But FWICS it all looks like
"one thread is trying to kick another one but it's not guaranteed to
work" kind of java feature, so I am not sure how much should I worry
about these things. What are the borders of what's acceptable?

Not sure.

				Grzegorz B. Prokopski

PS: Other notes:

* I'll probably send a note when the code for Thread.interrupt() is
put into the SVN (my private branch) for review.

* both JCVM and SableVM seem to share the same bug in wait()

--- sablevm-1.1.0.orig/src/libsablevm/java_lang_VMObject.c
+++ sablevm-1.1.0/src/libsablevm/java_lang_VMObject.c
@@ -259,7 +260,8 @@
            timeout.tv_nsec = now.tv_usec * 1000;

            timeout.tv_sec = timeout.tv_sec + (ms / 1000);
-           timeout.tv_nsec = timeout.tv_nsec + (ms % 1000) + ns;
+           timeout.tv_nsec =
+             timeout.tv_nsec + (ms % 1000) * 1000 * 1000 + ns;

Which usually makes quite big difference if one wants to wait,
say 500ms ;-) (which was previously turned into 500ns)

* See http://gadek.debian.net/SableVM-SymbolTest-Working.png !

which is one of the Sun's standard AWT tests. This _didn't_
really work previously, the symbols weren't drawn. Now it works
just like on Sun's JVM (minus classpath AWT glitches like lack
of text cursor in this edit window where "00" is visible). No
hacks used.

Unfortunatelly debbuggtk still doesn't work fully when it comes
to interrupt()ing another thread. I suspect that it might be
Classpath problem with InterruptedException routing.

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM





Thread: [Sablevm-developer] Thread.interrupted() - mess? (screenshot!)

sablevm-developer