Open System Services Programmer's Guide

The sigsetjmp() and siglongjmp() functions have an option to save and restore the signal
mask. This option can cause signals that were enabled by another thread to be inadvertently
masked.
When handling signals:
• Do not use the raise() function for an exception, and do not use the longjmp() function
to exit a synchronous signal handler. Simply returning from a signal handler is safe and is the
recommended practice.
• Use exception handlers instead of the setjmp() and longjmp() functions for threaded
OSS applications.
• Do not use the option of the sigsetjmp() and siglongjmp() functions that saves and
restores the signal mask. Doing so can cause signals enabled by another thread to be masked.
Spawning a New Process
Using the fork() or tdm_fork() function in a multithreaded environment can cause problems.
Applications can use either of these functions safely as follows: A parent process that has already
called a function can also use either of the fork functions to create a child process if the child
process calls any of the exec functions, the tdm_execve(), or tdm_execep() function
immediately upon its creation.
A threaded application might alternatively use pthread_atfork() to declare as many as three
fork handlers: a prepare handler called before the fork, a parent handler called after the fork in
the parent process, and a child handler called after the fork in the child process.
When a fork is called, only the calling thread is duplicated in the child process. The expected
usage of pthread_atfork() is for the prepare handler to acquire all mutex locks of interest to
the child, and the other two fork handlers to release them.
Beginning with the H06.24 and J06.13 RVUs, 64-bit OSS processes are supported. See “64-Bit
OSS Processes” (page 286) for details of creating 64-bit OSS processes.
Isolating Faults
Because all threads created by a process share the process address space, there is no address
space protection between the application threads in a process. One application thread can corrupt
data, causing other threads or the entire process to fail.
Single Versus Multiple Application Threads
OSS threaded applications can be classified as follows, in order of increasing complexity:
• “Programs With a Single Application Thread” (page 331)
• “Programs With Multiple Independent Application Threads” (page 332)
• “Programs With Multiple Interdependent Application Threads” (page 332)
Programs With a Single Application Thread
Externally, programs with a single application thread behave like standard, sequential (nonthreaded)
programs. The program begins execution in the main() procedure; it then calls other procedures
that, in turn, can call still other procedures. This type of application includes simple OSS client
programs.
Single Versus Multiple Application Threads 331