QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
    - Processes and Threads
      This chapter explains the concepts behind processes and threads, and the challenges of synchronization and scheduling. A thread is a flow of execution, and a process is a collection of threads. In the QNX OS, the schedulable entity is a thread, not a process.
      - Process and thread fundamentals
        Before we start talking about threads, processes, time slices, and all the other wonderful scheduling concepts, let's establish an analogy.
      - The kernel's role
        The house analogy is excellent for getting across the concept of synchronization, but it falls down in one major area. In our house, we had many threads running simultaneously. However in a single-processor system, only one thing can run at once.
      - Threads and processes
        Let's return to our discussion of threads and processes, this time from the perspective of a real live system. Then, we'll take a look at the function calls used to deal with threads and processes.
        Why processes?
        So why not just have one process with a zillion threads?
        Starting a process
        Let's now turn our attention to the function calls available to deal with threads and processes. Any thread can start a process; the only restrictions imposed are those that stem from basic security (file access, privilege restrictions, etc.). In all probability, you've already started other processes; either from the system startup script, the shell, or by having a program start another program on your behalf.
        Starting a process from the command line
        Starting a process from within a program
        You don't usually care about the fact that the shell creates processes—this is a basic assumption about the shell. In some application designs, you'll certainly be relying on shell scripts (batches of commands in a file) to do the work for you, but in other cases you'll want to create the processes yourself.
        Starting a process with the system() call
        The system() function is the simplest; it takes a command line, the same as you'd type it at a shell prompt, and executes it.
        Starting a process with the exec() and spawn() calls
        Let's look at some of the other process-creation functions.
        Starting a process with the fork() call
        Suppose you want to create a new process that's identical to the current process and have it run concurrently. You could approach this with a spawn() (and the P_NOWAIT parameter), giving the newly created process enough state information so it could set itself up. However, this can be extremely complicated; describing the current state of the current process can involve lots of data.
        Using fork() in a multithreaded process
        Using fork() in a multithreaded process can be tricky, especially if one thread calls fork() while other threads are in critical sections of code.
        Starting a process with the posix_spawn() call
        As we mentioned earlier, spawn() and spawnp() were in a POSIX draft, but never made it into the standard. Instead, POSIX added posix_spawn() and posix_spawnp().
        So what should you use?
        Obviously, if you're porting existing code, you'll want to use whatever it uses. For new code, you should avoid fork() if at all possible.
        Starting a thread
        Now that we've seen how to start another process, let's see how to start another thread.
      - More on synchronization
      - Scheduling and the real world
        So far we've talked about scheduling policies and thread states, but we haven't said much yet about why and when things are rescheduled.
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX OS, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX OS, their impact on scheduling and realtime, and some interrupt-management strategies.
    - Resource Managers
      In this chapter, we'll take a look at what you need to understand in order to write a resource manager. Resource managers are another distintive feature of QNX OS that allow you to access services through standard POSIX calls.
    - Sample Programs
      This appendix contains the complete versions of some of the sample programs discussed in this book.
    - Glossary
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Starting a process with the posix_spawn() call

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

As we mentioned earlier, spawn() and spawnp() were in a POSIX draft, but never made it into the standard. Instead, POSIX added posix_spawn() and posix_spawnp().

The posix_spawn() and posix_spawnp() functions were designed to let you specify how and what the child process should run. They were also designed to be easily extended; their arguments include a pointer to a posix_spawnattr_t structure that specifies spawn attributes, and a pointer to a posix_spawn_file_actions_t structure that specifies file actions (e.g., which file descriptors to close or duplicate in the child). These are both opaque structures, so there are functions that you can use to initialize, get, and set values within them.

For the attributes—some of which are POSIX, and some of which are QNX OS extensions—the first step is to set the members of the attribute structure to their default values by calling posix_spawnattr_init(). To set an attribute, call the appropriate posix_spawnattr_*() function and set the corresponding flag. To set the POSIX flags, call posix_spawnattr_setflags(); to set the QNX OS flags, call posix_spawnattr_setxflags(). For example:

To set the child's process group (a POSIX attribute), include POSIX_SPAWN_SETPGROUP in the call to posix_spawnattr_setflags(), and call posix_spawnattr_setpgroup() to set the process group.
To set the child's process runmask (a QNX OS attribute that controls which processors the child can run on), include POSIX_SPAWN_EXPLICIT_CPU in the call to posix_spawnattr_setxflags(), and call pthread_spawnattr_setrunmask_np() to set the runmask.

Setting the file actions is simpler because there are no flags to set; you just call posix_spawn_file_actions_init(), and then call the appropriate posix_spawn_file_actions_*() functions.

When you're ready to create the new process, call posix_spawn() or posix_spawnp(). The difference between these functions is as follows:

for posix_spawn() you specify the absolute path to the executable
for posix_spawnp() you specify the name of the executable file, and the function looks for it in the directories listed in your PATH environment variable

For more information, see the entry for these functions in the C Library Reference.

Page updated: March 05, 2025