[M3devel] Unix signals and Modula-3...

[Mika Nystrom]

Hello everyone,

I am in the process of bootstrapping the CVS head of CM3 on an old
FreeBSD-4.11 system, and at one point, when I replaced the old cm3
with the new cm3, the compiler got slower.  Not a little bit slower,
mind you, but about 10x slower.  I remember pointing this out to
the m3devel list... oh it must have been three or four years ago;
one of our grad students at Caltech (Karl Papadantonakis, also
author of the caltech-parser) was the first to notice what was going
on.

It has to do with Process.Wait.  (From ProcessPosix.m3.)  To repeat
what I said a few years ago, the problem lies here:

  CONST Delay = 0.1D0;
  BEGIN
    IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END;
    p.waitOk := FALSE;
    (* By rights, the SchedulerPosix interface should have a WaitPID
       procedure that is integrated with the thread scheduler. *)
    LOOP
      result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG);
      IF result # 0 THEN EXIT END;
      Thread.Pause(Delay)
    END;
    <* ASSERT result > 0 *>

In other words: if Process.Wait is called before the child process
is done, then the thread pauses 0.1 seconds.

In our local version of m3build, we duplicate the Wait code and set
the Delay to 0.0.  That's OK in a compiler, but it's not OK in
general, because you would chew up the CPU on a machine that was
doing a lot of long-term waiting.

The problem is that the fix that I suggested way back when requires
messing with Unix signals (catching SIGC[H]LD instead of using
waitpid), which is why I never submitted a fix to the repository,
because I am not sure what such a fix might interact with.  It seems
to me that the correct way of dealing with Unix signals is to have
a single thread that talks to the Unix system, registers signal
handlers, and takes care, via some object-oriented mechanism, of
calling back any M3 threads that are interested in the signals.
Would such a thing be possible?  Where are signals used in the
system today?

     Mika