> Hi everybody,
> reading the W Richard Stevens book 'Advanced
> Programming in the Unix environment' I got focalized by
> the paragraph 10.8 (10.8 Reliable Signal Terminology and Semantics)
> of the chapter 10. (10. Signals).
> This paragraph talks about the capability of
> POSIX.1 to allow a signal to be delivered once or more than once.
> (10.8 Reliable Signal Terminology and Semantics).
> I would like to have more infos about that and also
> know if SunOS 5.6 is POSIX.1 compliant.
> Also another issue I have is about the possibility
> for a signal ( in SunOS) to cause a system call 'read'
> to fail. There is any way to go around that and more :
> to queue the signal to check it later ?
> If anybody knows where I can find these answers
> please point me to these informations.
> Thanks a lot.
> Max
> --
> +-------------------------------------------------------+
> | Max Falco Verification and CAD Eng. |
> | T-Span Systems |
> | 3145 Porter Drive, Bldg A Ph : 650 494-7878 x128 |
> | Palo Alto, CA 94304 Fax : 650 494-7871 |
> +-------------------------------------------------------+
Do not know about Sun. However HP/UX 10.20's default shell is POSIX.2
after about 5 pages of signal(5) this is posix specific.
CHANGE HISTORY
First released in Issue 1.
Issue 4
The following changes are incorporated for alignment with the ISO
POSIX-1 standard:
+ The function declarations in this header are expanded to
full
ISO C prototypes.
+ The DESCRIPTION section is changed:
- to define the type sig_atomic_t
- to define the syntax of signal names and functions
- to combine the two tables of constants
- SIGFPE is no longer limited to floating-point
exceptions,
but covers all erroneous arithmetic operations.
The following change is incorporated for alignment with the ISO C
standard:
+ The raise() function is added to the list offunctions
declared
in this header.
Other changes are incorporated as follows:
+ A reference to <sys/types.h> is added for the definition
of
pid_t. This is marked as an extension.
+ In the list of signals starting with SIGCHLD, the
statement
"but a system not supporting the job control option is not
obliged to support the functionality of these signals" is
removed. This is because job control is defined as
mandatory
on Issue 4 conforming implementations.
+ Reference to implementation-dependent abnormal termination
routines, such as creation of a core file, in item ii in
the
defaults action list is marked as an extension.
Issue 4, Version 2
The following changes are incorporated for X/OPEN UNIX
conformance:
+ The SIGTRAP, SIGBUS, SIGSYS, SIGPOLL, SIGPROF, SIGXCPU,
SIGXFSZ, SIGURG, and SIGVTALRM signals are added to the
list
implementations.
+ The sa_sigaction member is added to the sigaction
structure,
and a note is added that the storage used by sa_handler
and
sa_sigaction may overlap.
+ The SA_ONSTACK, SA_RESETHAND, SA_RESTART, SA_SIGINFO,
SA_NOCLDWAIT, SS_ONSTACK, SS_DISABLE, MINSIGSTKSZ, and
SIGSTKSZ constants are defined. The stack_t, sigstack, and
siginfo structures are defined.
+ Definitions are given for the ucontext_t, stack_t,
sigstack,
and siginfo_t types.
+ A table is provided listing macros that are defined as
signal-specific reasons why a signal was generated.
Signal-specific additional information is specified.
+ The bsd_signal(), killpg(), _longjmp(), _setjmp(),
sigaltstack(), sighold(), sigrelse(), sigset(), and
sigstack()
functions are added to the list of functions declared in
this
header.
here is some POSIX.1 stuff
Posix Programmer's Guide
http://www.amazon.com/exec/obidos/ASIN/0937175730/webviator/002-74917...
get a jump on everybody
Posix. 4 : Programming for the Real World
http://www.amazon.com/exec/obidos/ASIN/1565920740/webviator/002-74917...
--
Bernie Chandler
http://www.nationwide.net/~bernie
by