SWT fileviewer fixes (PR=java/9253, PR=java/9254)

Mon Jan 13 23:04:00 GMT 2003

>>>>> "John" == John Murga <john@murga.org> writes:

John> I have attached fixes for the File problem (PR=java/9253) and
John> something that might get around the threads problem
John> (PR=java/9254)... these sit over the top the MingW patch.
One of the Windows-knowledgeable people will need to look at this in
more depth than I'm able to do.
John> + // On windows if the filename ends with ":" it is a drive, to retain the
John> + // standard java behaviour we have to add "\." to the end.
John> + if (total > 0 && buf[total-1] == ':')
John> + {
Isn't this only true if the drive name has a single letter?
(I'm guessing...)
John> - if (rval == WAIT_FAILED) return GetLastError();
John> - else if (rval == WAIT_TIMEOUT) return ETIMEDOUT;
John> + // The only error that java.lang.Object.wait() seems to care about is
John> + // interrupted, so if an error occurs the wait is "interrupted"
John> + if (rval == WAIT_FAILED) return _JV_INTERRUPTED;
John> + // A timeout is fine as long as it wasn't caused by an interrupt
John> + // else if (rval == WAIT_TIMEOUT) return ETIMEDOUT;
Actually we also care about _JV_NOT_OWNER.
What are the possible failure modes for WaitForMultipleObjects?
Note that _JV_INTERRUPTED means that Thread.interrupt was called.
Not all failures should return this.
The Windows _Jv_CondWait looks to me like it has some potential bugs.
It unlocks the passed-in mutex, which seems strange. It looks like
there is a race condition here. Also, what if the mutex is held more
than once (if the intent is to release it for the duration of the wait
then this code won't work properly).
Tom