Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!emory!hubcap!fouts
From: fouts@bozeman.ingr.com (Martin Fouts)
Newsgroups: comp.parallel
Subject: Re: Unix Signals and Parallel Programs
Message-ID: <9482@hubcap.clemson.edu>
Date: 27 Jun 90 12:46:07 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 51
Approved: parallel@hubcap.clemson.edu

In article <9360@hubcap.clemson.edu> richk@tera.com (Richard Korry) writes:

   I am interested how parallel Unix systems (Sequent, Convex, etc.) have
   defined the semantics of Unix signals in a parallel environment.

Poorly. (;-)

   For example, the man pages claim a signal "interrupts" executing system call.
   Does this map straight onto a parallel program, i.e. X threads running on
   Y processors are stopped when a signal arrives? How do they deal with user
   level signal handlers doing longjumps? Forgive me if this has already been
   dealt with in this news group.

Extending signal handling into the parallel environment leads to a
number of opportunities for reasonable men to disagree.  One of the
major ongoing debates in the POSIX 1003.4 attempt to standardize
threads has been about signal handling.  I've missed the last few
meetings, so I don't know which direction 1003.4 is going, but a quick
flawed overview of the issues include:

1) Visibility of a thread to the signal handling:
   How do I deliver a signal to a specific thread?  (Do I?)

2) Choice of thread to receive a signal sent to the process as a whole

3) The whole area of blocking/nonblocking i/o.

Philosophically, you can take the approach of extension by least
astounishment and try to extend signal handling to multithreaded
applications, or you can take the approach of inappropriate behavior
and simply claim that signals to a thread don't make sense.

I'm currently leaning towards the later personally, as signals were
never meant as an IPC mechanism in the first place.  An appropriate
variation would be to not allow signal handlers within multithreaded
applications:  signals would either be ignored or cause termination,
but could not be caught.  In this environment, exceptions would be
used where signals are currently used to indicate an exception, such
as FPE.

Marty

--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts  ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

If you can find an opinion in my posting, please let me know.
I don't have opinions, only misconceptions.