[Chicken-hackers] [PATCH] Reschedule when a thread blocked on thread-join! is forcibly resumed

[Evan Hanson]

Hi folks,

After some digging I've found a small bug in our srfi-18 implementation
that can have quite sinister effects on programs unlucky enough to be
affected by it. Here's the commit message:

> When a thread that's waiting on another with `thread-join!` is forced
> to execute -- usually on an interrupt, when the primordial thread is
> forcibly resumed via `##sys#force-primordial` -- it must return
> control to the scheduler if it can't yet be unblocked. Otherwise,
> execution will return to the point in the program where the interrupt
> occured, but without any bookkeeping to prevent that continuation from
> being executed *again* on an ensuing call to `##sys#schedule`.

Below is a program that triggers the issue. It starts a thread,
immediately blocks the primordial thread on it, then waits for I/O on a
file descriptor. A child process writes to the descriptor on interrupt.
When the program resumes from `thread-wait-for-i/o!`, a counter is
incremented. As you can see, this should only happen once.

    (use posix srfi-18)
    (set! (signal-handler signal/int) void)
    (thread-join!
     (thread-start!
      (lambda ()
        (define counter 0)
        (define-values (in out) (create-pipe))
        (process-fork (lambda ()
                        (file-close in)
                        (set! (signal-handler signal/int)
                          (lambda (_) (file-write out "shozbot")))
                        (sleep 60)))
        (file-close out)
        (printf "[1] press control-c~n")
        (thread-wait-for-i/o! in)
        (set! counter (add1 counter))
        (printf "[2] execution #~s~n" counter)
        (thread-yield!)
        (when (> counter 1)
          (printf "[3] double execution!~n")
          (exit 1)))))

Running this program (and doing what it says, pressing ^C when prompted)
should print steps [1] and [2], then exit. However, it currently yields
the following:

    $ csi -s amazing-test-case.scm
    [1] press control-c
    [2] execution #1
    [2] execution #2
    [3] double execution!

The fix for this is incredibly simple, just have a look and let me know
if you have any questions. The patch applies to master, of course. If it
looks good then once it's merged I will deal with patching and tagging a
new version of the srfi-18 egg in release/5.

Additionally, Jörg, I'd appreciate it if you could remove your
modifications to `##sys#force-primordial` and give this patch a try when
you have a chance. I think there's a good chance that the errors you
described in <address@hidden> were caused by this issue.

Cheers,

Evan