Re: [cp-patches] Implementing Thread.sleep() via Thread.wait()

[Mark Wielaard]

Hi,

On Thu, 2004-12-30 at 17:12 -0600, Archie Cobbs wrote:
> Good point.. I've reimplemented this in VMThread.sleep() instead.
> Let me know what you think.

Could you please supply a ChangeLog entry. that makes reviewing much
easier.

> *
> Confidentiality Notice: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and may contain confidential 
> and privileged information. Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all copies 
> of the original message.
> *

Please don't add such things to your emails. This is a public
mailinglist that is mirrored in a couple of places and forwarded to
public newsgroups.

> --- NEWS      30 Dec 2004 13:18:17 -0000      1.61
> +++ NEWS      30 Dec 2004 23:11:53 -0000
> @@ -14,9 +14,7 @@
>  * String and StringBuffer now call VMSystem.arraycopy() directly and don't
>    go through java.lang.System. Be careful to not initialize java.lang.System
>    early in the bootstrap sequence in your VM runtime interface classes.
> -* VMThread.sleep() will never be called with zero arguments (don't sleep).
> -  VMThread does not have to do any extra argument checking. Some (wrong)
> -  documentation about the behavior of this method has been updated.
> +* VMThread.sleep() now has a default non-native implementation.

Could you please keep the discription I added. And please mention that
the default implementation provided is a generic implementation that
ignores the nano-seconds argument. Runtime hackers are encouraged to
provide a more efficient version.

> +   * <p>
> +   * A zero length sleep is equivalent to <code>Thread.yield()</code>.

I think this is not a good idea. This is not supported by any
documentation. And I agree with you that it is probably a bug in the
implementation you tested and filed a bug report for the fact that
sleep(0) seems to ignore the interrupted state of the Thread. And if we
want to add this bug to our implementation (and I think we shouldn't)
why Thread.yield(), why not just return?

> -    if (ns > 0 && ms == 0)
> +    // JDK compatibility: sleep(0) is equivalent to Thread.yield()
> +    if (ms == 0 && ns == 0)
>        {
> -     ms = 1;
> -     ns = 0;
> +     Thread.yield();
> +     return;
>        }

Note that the documentation of Thread.sleep() (JCL2v1) says that if
millis is 0, nonzero nanos is treated as 1 millisecond. We could not
support that (since I agree that it is a bit strange definition and it
might come from how it is implemented - rounding up the nanos like you
do now in VMThread.sleep()), but then we should clearly document that.
 
> -     long end = System.currentTimeMillis() + ms;
> +     // Compute end time, but don't overflow
> +     long now = System.currentTimeMillis();
> +     long end = now + ms;
> +     if (end < now)
> +         end = Long.MAX_VALUE;

Nice catch.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part