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 | <CAChcVum5+Lw9Xq-_QgyJ4rxoq=nMfnPOcE2Y_ggihLiVJHMLfg@mail.gmail.com> |
On Fri, Aug 30, 2019 at 6:43 PM Pavel Rappo <[email protected]> wrote: > 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. Revisiting this, I have probably made a poor word choice. I should've used the word "uniform" instead of "consistent". Meaning that when one uses TimeUnit, one always knows what a 0 (zero) timeout means. Thread.sleep seems to be the only method from classic (pre Java 5) concurrency that doesn't say anything about its behavior when zero is passed. And it kinda makes sense when you think about it. TimeUnit eliminates this need to think. And to be honest I like it. Maybe that should be made more explicit by mentioning that design choice in the class-level javadoc though. Something to the effect that "unless otherwise stated... methods that accept timeout argument... are no-op when that argument is less than or equal to zero...". _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest