This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
swt fileviewer
- From: "Erik Poupaert" <erik dot poupaert at chello dot be>
- To: "John Murga" <john at murga dot org>
- Cc: <java at gcc dot gnu dot org>
- Date: Sat, 4 Jan 2003 22:39:05 +0100
- Subject: swt fileviewer
The remaining bug in swt FileViewer.java, is definitely related to
threading.
After a workerThread.start() (line 1695), the method object.wait() (line
123) works fine.
After a object.notifyAll() (line 1691), the thread continues from it wait;
which is also fine. But from then on invokations of the method object.wait()
(line 123) will not cause the thread to wait any longer.
I can clearly see object.wait() getting invoked and not waiting!!!
The effect is that the table view gets refreshed continuously; which
explains the strange behaviour of FileViewer.java.
I've looked at the native methods, supporting object.wait() and
object.notifyAll() and I notice something weird.
While posix-threads.cc/_JvCondWait() will return (_JV_NOT_OWNER,
_JV_INTERRUPTED, 0), which are exactly the return codes that
java::lang::Object::wait() checks on, win32-threads.cc/_JvCondWait(), will
return (GetLastError(), ETIMEOUT, 0).
Especially GetLastError() is rather alarming. If there's a problem with
WaitForMultipleObjects() (WAIT_FAILED), java::lang::Object::wait() may never
notice, because it does not check on such values.
Why are the return codes to java::lang::Object::wait() different for posix
and win32? Shouldn't they return the same values to
java::lang::Object::wait()? Just a stupid question ...
By the way, stepping through these native functions with gdb must be really
interesting!