[Chicken-hackers] [PATCH] Fix for #877

[Peter Bex]

Hi all,

I finally took a shovel and dug in deep into #877.
It's a very tricky one and I think it's been so elusive due
to the fact that the bug *probably* only crops up on machines
with multiple CPU (cores).

At least it's relatively easy to detect the error and clean up
the child, and abort the test run with a failure, so the test part
of the attached patch is definitely an improvement.  The patch
also includes a fix for runtime.c for what seems to be the cause.

I noticed that whenever it would fail, the test would print only
letters, no numbers or dots.  So, it looked like the child was no
longer responding to the parent's signals OR spinning in its threads
which print dots and underscores.  This seems to indicate it is flooded
with signals or something.  The icky signal queueing code in runtime.c
takes care not to queue up more than 100 signals, and it doesn't queue
up timer interrupts in an attempt not to flood itself, but this doesn't
help you when someone else is flooding you from the outside.  So now
it will drop signals more aggressively, by ignoring signals that have
already been queued.  Hopefully this will help.  At least I have tried
repeatedly on the call-cc.org server and I can no longer trigger the
failure situation (which was relatively easy to reproduce on that
machine, it would fail about once every 5 runs).

If that's not enough we could make a queue the size of the total number
of available signals.  This would be slightly faster, but could also
be an extremely big vector on some operating systems(?).  I think
something like that has been suggested before by Jerry.  For now it
doesn't necessary or likely that so many *different* signals would
arrive at the same time, not even in case of an attack: you can't send
signals to processes you don't own.

Sorry for rambling.

Cheers,
Peter
-- 
http://www.more-magic.net

0001-Fix-race-condition-in-877.patch
Description: Text document