Re: More accurate wording for java.util.concurrent.TimeUnit.sleep
Pavel Rappo via Concurrency-interest <[email protected]>
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CAChcVukTVRkTbW00rnrUEpq331WngzqpdBpEu50qrn6fgbdS=g@mail.gmail.com> |
> On Fri, Aug 30, 2019 at 6:00 PM Martin Buchholz <[email protected]> wrote: > > I've been a steady advocate of "at least" semantics for methods that specify a duration, including sleep. > > https://bugs.openjdk.java.net/browse/JDK-6313903 Then it seems like you are in favor of changing the Thread.sleep spec. > Pavel, if you need to do something surely at 9am, set the alarm for 8am, not 9am! I never said in that example that the alarm is set for 9 am. I shouldn't have used this analogy, to be honest. Analogies typically lead to more confusion. > I agree that if Thread.sleep(0) is not really a no-op then TimeUnit.sleep(0) should do the same thing. Hm... We have to think carefully about that. My guess would be that this "avoid Thread.sleep(0)" behavior has something to do with consistency. You see, 0 (zero) can have a special meaning in some APIs. For instance, java.util.concurrent treats it literally. Zero or no time at all. On the other hand, java.net API typically treats it "as an infinite timeout" (e.g. Socket.connect(SocketAddress, int)). java.lang has it both ways. Thread.sleep is like java.util.concurrent in that respect, but Thread.join and Object.wait(long) are like java.net. Having said that, I think TimeUnit tries to be consistent. _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest