On Sun, Mar 06, 2011 at 12:27:15PM +0100, Matthias Kilian wrote:
> On Sun, Mar 06, 2011 at 11:06:06AM +0100, Matthias Kilian wrote:
> > This is similar to the results on amd64, except for
> > t/spec/S29-context/sleep.t, which passes on amd64.
> [...]
> > Running it through ktrace(1) and then reading the trace with kdump
> > -R shows that `sleep' is implemented using poll(2), but using a
> > wrong timeout parameter, which is different during several test
> > runs:
> > 
> >     25090 perl6    0.000023 CALL  poll(0x5a9a0000,0x1,0x6abc)
> >     25090 perl6    27.334955 RET   poll 0
> > 
> >      7918 perl6    0.000024 CALL  poll(0x5cf04000,0x1,0x6b75)
> >      7918 perl6    27.511825 RET   poll 0
> > 
> >     22718 perl6    0.000024 CALL  poll(0x5e472000,0x1,0x6776)
> >     22718 perl6    26.491583 RET   poll 0
> > 
> > So something seems to be wrong with the way rakudo calculates the
> > timeout parameter to poll(2), at least on mips64el.
> 
> FWIW, amd64 has the same strangeness, but here the timeout parameter
> is smaller than on mips64el, so it passes the test case. ktrace/kdump
> examples on amd64:
> 
>         7989 perl6    0.000004 CALL  poll(0x202a42800,0x1,0x14ef)
>         7989 perl6    5.361508 RET   poll 0
> 
>        13736 perl6    0.000004 CALL  poll(0x210134400,0x1,0x15a4)
>        13736 perl6    5.544580 RET   poll 0
> 
> Ciao,
>       Kili
> 
> 

Ok, this is most likely the same bug as on macppc.

It may, however, be a bug in parrot as well as in rakudo. I can't find
an obvious error in the rakudo code:

src/core/system.pm:

sub sleep($seconds = Inf) {         # fractional seconds also allowed
    my $time1 = time;
    if $seconds ~~ Inf {
        pir::sleep__vN(1e16) while True;
    } else {
        pir::sleep__vN($seconds);
    }
    my $time2 = time;
    return $time2 - $time1;
}

The implementation of pir::sleep seems to be dependent on whether parrot
is threaded or not. (Look in src/scheduler.c, Parrot_cx_schedule_sleep()).
Is that the case on macppc and mips64el? (Parrot_sleep() just calls
sleep(3) on OpenBSD, so it probably is ...). The other method
effectively calls pthread_cond_timedwait(). If there is indeed a bug in
that function (still hard to imagine), we could work around it by
building parrot without threads on those platforms. Can you (or Landry)
try if that fixes the rakudo test (Configure.pl --without-threads)?

Pascal

Reply via email to