Jump to main content
Index
Advanced search
  1. Home
  2. 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 QNX Neutrino 7.1.

  3. OS Components & Operations

  4. System Architecture

    The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.

  5. Process Manager

    The process manager is capable of creating multiple POSIX processes (each of which may contain multiple POSIX threads).

  6. Process management

    The first responsibility of procnto is to dynamically create new processes. These processes will then depend on procnto's other responsibilities of memory management and pathname management.

  7. Process primitives

  • QNX Momentics IDE User's Guide

    This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics 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 QNX Neutrino 7.1.

    • Quickstart Guide

    • OS Components & Operations

      • Adaptive Partitioning User's Guide

      • Boot Optimization Guide

        The Boot Optimization Guide describes techniques you can use to reduce the time from your board's initial power on until you have a fully functional QNX system running on the board.

      • Building Embedded Systems

        The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX Neutrino RTOS embedded systems.

      • Core Networking Stack User's Guide

        This guide introduces you to the QNX Neutrino Core Networking stack and its manager, io-pkt.

      • Customizing a BSP

        While QNX provides Board Support Packages (BSPs) for many common platforms and their individual variants, in some cases, you need a BSP for a board that QNX does not provide. If this is the case, you can modify a QNX BSP or develop your own.

      • Device Publishers Developer's Guide
      • High Availability Framework Developer's Guide
      • High-Performance Networking Stack (io-sock) User's Guide

        This guide contains instructions for implementing and using the QNX Neutrino High-Performance Networking Stack and its manager, io-sock.

      • Instant Device Activation
      • Migrating to QNX SDP 7.1
      • PCI Server User's Guide

      • Persistent Publish/Subscribe Developer's Guide

      • Platform-independent Publish/Subscribe Developer's Guide

        This guide is intended for application developers who want to use the Platform-independent Publish Subscribe (PiPS) framework to exchange information with other applications. First, the overall PiPS design and data-exchange model are explained. Then, tutorials on using PiPS are given. These tutorials cover key tasks such as selecting a publish-subscribe provider to use and writing plugins that read and write custom data types.

      • QDB Developer's Guide
      • QNX Helpers Developer's Guide

        These libraries provide QNX helpers, including helpers that assist with logging, string conversion, and number and type sizes.

      • SMMUMAN User's Guide

      • System Analysis Toolkit (SAT) User's Guide
      • System Architecture

        The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.

        • The Philosophy of the QNX Neutrino RTOS

          The primary goal of the QNX Neutrino RTOS is to deliver the open systems POSIX API in a robust, scalable form suitable for a wide range of systems—from tiny, resource-constrained embedded systems to high-end distributed computing environments. The OS supports several processor families, including x86 and ARM.

        • The QNX Neutrino Microkernel

          The microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX Neutrino message-passing services.

        • Interprocess Communication (IPC)

          Interprocess Communication plays a fundamental role in the transformation of the microkernel from an embedded realtime kernel into a full-scale POSIX operating system. As various service-providing processes are added to the microkernel, IPC is the glue that connects those components into a cohesive whole.

        • The Instrumented Microkernel

          An instrumented version of the microkernel (procnto-instr) is equipped with a sophisticated tracing and profiling mechanism that lets you monitor your system's execution in real time. The procnto-instr module works on both single-CPU and SMP systems.

        • Multicore Processing

        • Process Manager

          The process manager is capable of creating multiple POSIX processes (each of which may contain multiple POSIX threads).

          • Process management

            The first responsibility of procnto is to dynamically create new processes. These processes will then depend on procnto's other responsibilities of memory management and pathname management.

            • Process primitives

              • posix_spawn()

                The posix_spawn() function creates a child process by directly specifying an executable to load.

              • spawn()

                The QNX Neutrino spawn() function is similar to posix_spawn().

              • fork()

                The fork() function creates a new child process by sharing the same code as the calling process and duplicating the calling process's data to give the child process an exact copy. Most process resources are inherited.

              • exec*()

                The exec*() family of functions replaces the current process with a new process, loaded from an executable file. Since the calling process is replaced, there can be no successful return.

            • Process loading

              Processes loaded from a filesystem using the exec*(), posix_spawn() or spawn() calls are in ELF (Executable and Linking Format).

          • Memory management

            The virtual memory system implements the POSIX model for memory management along with some QNX Neutrino extensions.

          • Memory accounting

          • Pathname management

            I/O resources aren't built into the microkernel, but are instead provided by resource manager processes that may be started dynamically at runtime. The procnto manager allows resource managers, through a standard API, to adopt a subset of the pathname space as a domain of authority to administer.

        • Dynamic Linking

          In a typical system, a number of programs will be running. Each program relies on a number of functions, some of which will be standard C library functions, like printf(), malloc(), write(), etc.

        • Resource Managers

          To give the QNX Neutrino RTOS a great degree of flexibility, to minimize the runtime memory requirements of the final system, and to cope with the wide variety of devices that may be found in a custom embedded system, the OS allows user-written processes to act as resource managers that can be started and stopped dynamically.

        • Filesystems

          The QNX Neutrino RTOS provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.

        • PPS

          The QNX Neutrino Persistent Publish/Subscribe (PPS) service is a small, extensible publish/subscribe service that offers persistence across reboots. It's designed to provide a simple and easy-to-use solution for both publish/subscribe and persistence in embedded systems, answering a need for building loosely connected systems using asynchronous publications and notifications.

        • Character I/O

          A key requirement of any realtime operating system is high-performance character I/O.

        • Networking Architecture

          As with other service-providing processes in the QNX Neutrino RTOS, the networking services execute outside the kernel. Developers are presented with a single unified interface, regardless of the configuration and number of networks involved.

        • Native Networking (Qnet)

          In the Interprocess Communication (IPC) chapter earlier in this manual, we described message passing in the context of a single node. But the true power of the QNX Neutrino RTOS lies in its ability to take the message-passing paradigm and extend it transparently over a network of microkernels. This chapter describes QNX Neutrino native networking (via the Qnet protocol).

        • TCP/IP Networking

          As the Internet has grown to become more and more visible in our daily lives, the protocol it's based on—IP (Internet Protocol)—has become increasingly important. The IP protocol and tools that go with it are ubiquitous, making IP the de facto choice for many private networks.

        • High Availability

          The term High Availability (HA) is commonly used in telecommunications and other industries to describe a system's ability to remain up and running without interruption for extended periods of time.

        • Adaptive Partitioning
        • What is Real Time and Why Do I Need It?

        • Glossary
      • Technotes
      • User's Guide

        The QNX Neutrino User's Guide is intended for all users of a QNX Neutrino RTOS system, from system administrators to end users.

    • Audio & Graphics API

    • Multimedia

    • Networking Middleware

    • Programming

    • Sensor Framework

    • System Security Guide

      The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.

    • Utilities & Libraries

  • QNX Hypervisor

    The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.

  • QNX Software in the Cloud

    QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).

  • QNX Advanced Virtualization Frameworks User's Guide

    This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.

  • Typographical Conventions, Support, and Licensing

    This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Process primitives

The process primitives include:

posix_spawn()
POSIX
spawn()
QNX Neutrino
fork()
POSIX
exec*()
POSIX
Page updated: March 12, 2026
Related information
  • Processes and Threads (Getting Started with QNX Neutrino)
  • Processes (QNX Neutrino Programmer's Guide)
  • environ()
  • execle()
  • execl()
  • execlpe()
  • execlp()
  • execve()
  • execv()
  • execvpe()
  • execvp()
  • fork()
  • posix_spawn()
  • pthread_create()
  • spawn()
  • spawnle()
  • spawnl()
  • spawnlpe()
  • spawnlp()
  • spawnp()
  • spawnve()
  • spawnv()
  • spawnvpe()
  • spawnvp()