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

[Tony Hosking]

I'm assuming that waitpid hanging when using system threads is not a  
problem, since the system thread scheduler will schedule other  
threads around the waiting one.  The issue is only for the user-level  
threads implementation where a thread blocking on a waitpid call  
would prevent other threads being scheduled.

On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote:

> 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