[armedbear-devel] hang with threads:object-wait

[Erik Huelsmann]

Hi James,

Thanks for confirming that.

What would you consider the best option when the timeout value becomes too
close to 0? I see 2:

1. Don't wait.
2. Wait at least 1 ns

Bye,

Erik.
 On Feb 1, 2014 7:50 PM, "James M. Lawrence" <llmjjmll at gmail.com> wrote:

> Hi, this fixes time=0 and time=0.0001, but it still hangs with
> time=0.000000001 and smaller positive values.
>
>
> On Sat, Feb 1, 2014 at 11:36 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
> > Hi James,
> >
> > My thinking is that the wait time is being rounded to zero, which might
> be
> > used internally by Java to encode an indefinite wait.
> >
> > Does the patch below work for you?
> >
> > Bye,
> >
> > Erik.
> >
> >
> > Index: LispThread.java
> > ===================================================================
> > --- LispThread.java (revision 14464)
> > +++ LispThread.java (working copy)
> > @@ -1004,11 +1004,12 @@
> >      };
> >
> >
> > +  private static DoubleFloat factor1000 = new DoubleFloat(1000);
> > +
> >      public static final long javaSleepInterval(LispObject lispSleep)
> > -
> >      {
> >          double d =
> > -            checkDoubleFloat(lispSleep.multiplyBy(new
> > DoubleFloat(1000))).getValue();
> > +
>  checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();
> >          if (d < 0)
> >              type_error(lispSleep, list(Symbol.REAL, Fixnum.ZERO));
> >
> > @@ -1015,6 +1016,17 @@
> >          return (d < Long.MAX_VALUE ? (long) d : Long.MAX_VALUE);
> >      }
> >
> > +    public static final int javaSleepNanos(LispObject lispSleep)
> > +    {
> > +        double d = // d contains millis
> > +
>  checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();
> > +        double n = d*1000000; // n contains nanos
> > +        d = 1.0e6*((long)d); // convert rounded millis to nanos
> > +        n = n - d; // retain nanos not in millis
> > +
> > +        return (n < Integer.MAX_VALUE ? (int) n : Integer.MAX_VALUE);
> > +    }
> > +
> >      @DocString(name="sleep", args="seconds",
> >      doc="Causes the invoking thread to sleep for SECONDS seconds.\n"+
> >          "SECONDS may be a value between 0 1and 1.")
> > @@ -1025,7 +1037,8 @@
> >          {
> >
> >              try {
> > -                Thread.sleep(javaSleepInterval(arg));
> > +      Thread.sleep(javaSleepInterval(arg),
> > +   javaSleepNanos(arg));
> >              }
> >              catch (InterruptedException e) {
> >                  currentThread().processThreadInterrupts();
> > @@ -1208,7 +1221,8 @@
> >
> >          {
> >              try {
> > -
>  object.lockableInstance().wait(javaSleepInterval(timeout));
> > +      object.lockableInstance().wait(javaSleepInterval(timeout),
> > +     javaSleepNanos(timeout));
> >              }
> >              catch (InterruptedException e) {
> >                  currentThread().processThreadInterrupts();
> >
> >
> >
> >
> > On Sat, Feb 1, 2014 at 2:54 PM, James M. Lawrence <llmjjmll at gmail.com>
> > wrote:
> >>
> >> (defun test ()
> >>   (let ((object (cons nil nil)))
> >>     (threads:synchronized-on object
> >>       (threads:object-wait object 0.0001))))
> >>
> >> For times between 0 and 0.0001 this appears to hang indefinitely. No
> >> problem with times above 0.001.
> >>
> >> The context is the new timeout option for
> bordeaux-threads:condition-wait,
> >>
> >>
> >>
> https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#L101
> >>
> >> 1.3.0-dev-svn-14623
> >> Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20
> >> i386-Linux-3.2.0-24-generic-pae
> >>
> >> Best,
> >> lmj
> >>
> >
> >
> >
> > --
> > Bye,
> >
> > Erik.
> >
> > http://efficito.com -- Hosted accounting and ERP.
> > Robust and Flexible. No vendor lock-in.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20140201/fba3021e/attachment.html>