[Chicken-hackers] [PATCH][5] Fix hanging srfi-18 egg tests due to scheduler bug

[Peter Bex]

Hi all,

Now that our Salmonellas are working again, they have started to hang:
on all the Salmonella boxes, the last available results for the chicken-5
branch are those of yesterday.  chicken-5 eggs can once again be correctly
installed and tested, and srfi-18 contains code that causes the test
suite to hang.

thread-sleep! with a flonum argument.  The scheduler itself uses
(current-milliseconds) in its calculations.  This used to return
a flonum, which would eventually lose a lot of precision for very
long-running processes.  That's why, with the numbers integration,
I changed it to always return an exact integer (ie, eventually it
starts returning bignums).  When I integrated the numbers code, I
changed all the scheduler's calculations dealing with floating point
to use generic operators.

Unfortunately, the srfi-18 egg is still invoking
##sys#thread-block-for-timeout! with flonums.  This is what causes
the srfi-18 tests to hang in srfi-18-signal-test.scm.
srfi-18 simply passes on whatever numeric type the user passes
as thread-join! and thread-sleep!'s timeout arguments.  The tests
indeed use flonums, which means C_msleep() will receive a flonum.
Because I removed the assumption that flonums are used in the scheduler,
I also removed the call to C_quickflonumtruncate() which was done
in order to return a fixnum.

So, C_msleep() still assumes it will receive a fixnum, which is not
true if you let a thread sleep for a flonum amount of seconds, which
the srfi-18 tests do.  And calling C_unfix() unsafely on a flonum results
in very large numbers, effectively letting it sleep "forever".

The attached patch improves the situation by first rounding the number
that will be passed to C_msleep(), and ensuring it's an exact integer.
I've also changed it so that it accepts bignums, to avoid the
potential precision loss I mentioned before (though you'd only get
that problem when sleeping for very long time, I think, because the
numbers have been changed from a deadline timestamp to a sleep amount
which should be a relatively small number).

Interestingly, because of the way the SRFI-18 egg is coded, it should
now be possible to pass _any_ type of number as a timeout value!  That
means you can now do (thread-sleep! 1/16), for example.  If you pass
in a complex number, you'll just get an error about not being able to
compare complex numbers.  We could perhaps improve that by changing the
srfi-18 egg's compute-time-limit procedure to check that it receives a
real number rather than an arbitrary number.

I've tested the patch on Linux/x86-64 and Windows/x86 (both Cygwin and
Mingw).  It works, but I did get some strange problems in Mingw; running
the srfi-18 tests in mingw resulted in the message:

'"csc"' is not recognized as an internal or external command, operable
or batch file.

When I tried to compile the srfi-18-tests myself, I got an error that
libchicken.dll wasn't installed; it appears that there's a problem with
the Makefile.

These are separate issues, though:  (use srfi-18) (thread-sleep! 0.25)
works in csi on mingw, as well as (thread-sleep! 1/2), for example.

Cheers,
Peter

0001-Ensure-scheduler-calls-C_msleep-with-an-integral-val.patch
Description: Text Data

signature.asc
Description: Digital signature