While browsing through Hotspot code, I noticed a bug in the sleep routine. The appended program is supposed to sleep for around 50 days, however, it does not. Feel free to run it on windows, it will terminate at once. The problem is that the Thread.sleep parameter is a 64-bit value, while the Os sleep accepts a 32 bit parameter. Instead of a loop, we truncate and use only the lower 32-bits, resulting in a 0 ms duration sleep.

Srdjan

public class SleepTest {
  public static void main(String s[]) {
    long t = 1L << 32;
    System.out.println("Sleeping for : " + t + " ms.");
    try {
      Thread.sleep(t);
    } catch (InterruptedException i) {
      System.out.println("interrupted");
    }
    System.out.println("done");
  }
}
----

It turns out there are many other bugs involved with Thread.sleep(), on Solaris
and Linux. First, too-large delay values can result in an instant
return with no sleep at all because the OS has rejected the system call with an
EINVAL. Second, signals interrupting the poll or select can cause the sleep to
be truncated. On Linux there is an almost correct attempt to restart the delay
with adjusted time but if signals come too frequently that fails also. The issue
with EINTR handling is closely related to bug 4178050.

###@###.### 2001-09-07