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

[Mika Nystrom]

Ah yes, you are right.  The original issue is that waitpid would
hang the whole runtime and that should not happen with system
threads.  If using system threads, waitpid should be called with a
third argument of zero, I believe.  Is this already happening?
If not, make the change and if you have a fast machine you may
see a spectacular speedup in your compile times.

I suppose the easiest solution to this problem is simply to move
all active targets to system threads... 

Still, there are some other areas where Unix signals might be of
interest.  I am thinking of things like interfacing with readline
and other C-based libraries that use signals for concurrency.  When
I put a readline interface on some Modula-3 programs, I wound up
using an external C program to do readline processing and then
communicating over a pipe or TCP connection, because dealing
with signals seemed like such a hassle.

      Mika

Tony Hosking writes:
>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