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

[Tony Hosking]

The system threads pthread implementation uses a signal and a  
semaphore to stop/start threads for GC, Other than that, I don't  
believe signals are being used anywhere else in the run-time system.

Also, I should point out that there may be value in retaining the  
current user-level threads implementation for all targets (we still  
need to fix some to use setcontext/getcontext instead of setjmp/ 
getjmp), in which case the same issue applies.  I wonder if it makes  
sense to implement a variant of waitpid inside the threads  
implementation to do the right thing.  We could use a signal there to  
catch SIGCHLD appropriately in the ThreadPosix implementation and  
leave it alone with ThreadPThread.

What do you think?

On Dec 18, 2007, at 6:43 PM, Mika Nystrom wrote:

>
> 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