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

[Mika Nystrom]

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

Oh, yes I wasn't suggesting dropping the user-level threads.  I was
just thinking that if most targets can use system threads, maybe
it's OK if there's a 0.1 second delay on the others.  After all,
most people don't seem to have noticed that it's been this way all
these years :)  (Although it does get more obvious now that computers
are faster and compile times aren't getting shorter on those targets.)

I also think user-level threads can turn out to be important when
system threads perform poorly for whatever reason.  I know this was
a big problem for some people I knew who were working with threads
in Java, that when they used system threads for code that did very
little work and lots of threadswitching, user-level threads were
an order of magnitude faster.

I suppose that ThreadPosix also uses signals to know when to switch
contexts?  Since it already deals with signals it shouldn't be too
difficult to incorporate the waitpid business.  But yes, it seems to me
that since the implementation of Process.Wait's waiting for the child
to exit depends on what kind of threading library is being used, that
part of it ought/could conveniently be part of the threading library's
interface.

     Mika