Development Environment Configuration

For efficient C++ development on Linux, configure VSCode with the Remote - SSH extension. This allows writing code locally while executing on a remote Linux host.

1. Extension Installation: Install the Remote - SSH plugin via the marketplace.
2. Connection: Use the command palette (F1) to configure Remote-SSH. Enter your connection string (e.g., ssh username@host).
3. Workspace: Open the remote filesystem in the Explorer pane. Create project directories synchronously betweeen local and remote machines.
4. Compilation: Utilize the integrated terminal (Ctrl + ~) for building and running executables directly on the target OS.

IPC Fundamentals

Conceptual Overview

Inter-Process Communication (IPC) enables indepandent processes to exchange data or coordinate actions. Key scenarios include:

• Data Transfer: Sending information from one process to another.
• Resource Sharing: Accessing common resources like memory blocks or devices.
• Synchronization: Notifying events or managing state changes.
• Control Flow: Debugging or controlling execution paths of other processes.

Despite process isolation being fundamental to OS stability, cooperation requires mechanisms to cross these boundaries. The goal is to achieve data interaction without compromising independence.

Mechanisms and Kernel Role

Processes cannot directly access each other's virtual memory spaces. Therefore, communication must occur through an intermediary. The operating system provides shared kernel resources that act as the bridge.

The core strategies are:

1. Pipes: File-based or memory-based streams suitable for parent-child relationships or named files.
2. System V APIs: Focuses on legacy local IPCs like Shared Memory, Message Queues, and Semaphores.
3. POSIX Standards: Modern, portable interfaces supporting networking capabilities across hosts.

Essentially, IPC relies on shared kernel buffers. Whether implemented as a file structure (struct file) or anonymous memory, the kernel maintains the resource so multiple processes can read from or write to it safely.

Anonymous Pipes

Anonymous pipes facilitate communication primarily between related processes (parent/child). They function as a stream-oriented channel within kernel memory.

Implementation Details

• Creation: Use the pipe() system call.
• File Descriptors: Returns two integers. Index 0 is for reading; Index 1 is for writing.
• Scope: Inherited by child processes upon fork().
• Flow: Unidirectional. Bidirectional communication requires two pipes.

Code Example: Basic Sender/Receiver

The following example demonstrates creating a pipe, spawning a child, and exchanging messages. Variables have been standardized for clarity.

#include <iostream>
#include <unistd.h>
#include <sys/wait.h>
#include <cstring>
#include <cerrno>

using namespace std;

int main() {
    int fds[2]; // Standardized fd array
    if (pipe(fds) == -1) {
        perror("Pipe creation failed");
        return 1;
    }

    pid_t pid = fork();
    if (pid == -1) {
        perror("Fork failed");
        return 1;
    }

    if (pid > 0) {
        // Parent Process: Writer
        close(fds[0]); // Close read end
        
        const char* msg = "Hello Child";
        write(fds[1], msg, strlen(msg));
        cout << "Parent sent message." << endl;
        
        close(fds[1]); // Close after sending
        wait(nullptr); // Wait for child exit
    } else {
        // Child Process: Reader
        close(fds[1]); // Close write end
        
        char buffer[64] = {0};
        ssize_t n = read(fds[0], buffer, sizeof(buffer) - 1);
        
        if (n > 0) {
            buffer[n] = '\0';
            cout << "Child received: " << buffer << endl;
        }
        
        close(fds[0]);
    }

    return 0;
}

Advanced: Worker Pool Simulation

To simulate a process pool, a master process creates multiple worker children connected via individual pipes. A random selection strategy distributes tasks.

#include <iostream>
#include <vector>
#include <cstdlib>
#include <ctime>
#include <unistd.h>
#include <sys/wait.h>

#define WORKER_COUNT 3

// Task definitions
class Task {
public:
    void execute(int id) {
        std::cout << "Worker " << getpid() << " executing task ID: " << id << std::endl;
    }
};

void worker_process(int read_fd) {
    int task_id = 0;
    while (true) {
        ssize_t bytes_read = read(read_fd, &task_id, sizeof(task_id));
        if (bytes_read <= 0) break; // EOF or Error

        Task t;
        t.execute(task_id);
    }
}

int main() {
    std::vector<pid_t> pids;
    std::vector<int> write_fds;
    
    srand(time(NULL));
    
    // Initialize workers
    for (int i = 0; i < WORKER_COUNT; ++i) {
        int fds[2];
        if (pipe(fds) != 0) continue;

        pid_t pid = fork();
        if (pid == 0) {
            close(fds[1]); // Worker closes write end
            close(STDIN_FILENO); // Clean up unnecessary FDs
            worker_process(fds[0]);
            _exit(0);
        }
        
        close(fds[0]); // Master closes read end
        pids.push_back(pid);
        write_fds.push_back(fds[1]);
    }

    // Dispatch Tasks
    try {
        for (int i = 0; i < 10; ++i) {
            int choice = rand() % WORKER_COUNT;
            int task = i;
            // Send to selected worker
            write(write_fds[choice], &task, sizeof(task));
        }
    } catch (...) {}

    // Shutdown
    for (int fd : write_fds) {
        close(fd);
        waitpid(-1, nullptr, 0);
    }

    return 0;
}

Named Pipes (FIFOs)

Named pipes allow communication between unrelated processes by using a pathname in the filesystem. Unlike anonymous pipes, they exist as inode entries on disk.

Key Characteristics

• Persistence: The file exists until explicitly removed.
• Access: Processes open the file path similar to regular I/O.
• Blocking: Opening for read-only may block until a writer connects, and vice versa.
• Creation: Created via mkfifo syscall or shell command.

Code Example: Client-Server Model

This example uses a named pipe to establish a connection between a server listener and a client sender.

Header Definitions

#ifndef PIPE_COMM_H
#define PIPE_COMM_H

#include <string>
static const std::string P_PATH = "./system.pipe";
static const int BUF_SIZE = 128;

#endif

Server Logic

#include <iostream>
#include <fstream>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include "PIPE_COMM_H"

int main() {
    struct stat st;
    if (!stat(P_PATH.c_str(), &st)) {
        unlink(P_PATH.c_str()); // Ensure clean start
    }

    if (mkfifo(P_PATH.c_str(), 0666) != 0) {
        perror("Create FIFO failed");
        return 1;
    }

    // Block waiting for client connection
    int fd = open(P_PATH.c_str(), O_RDONLY);
    if (fd < 0) {
        perror("Open Pipe failed");
        return 1;
    }

    char buf[BUF_SIZE];
    while (true) {
        memset(buf, 0, sizeof(buf));
        ssize_t len = read(fd, buf, sizeof(buf) - 1);
        if (len == 0) break; // Client disconnected
        std::cout << "Server received: " << buf << std::endl;
    }

    close(fd);
    unlink(P_PATH.c_str());
    return 0;
}

Client Logic

#include <iostream>
#include <fcntl.h>
#include <unistd.h>
#include "PIPE_COMM_H"

int main() {
    int fd = open(P_PATH.c_str(), O_WRONLY);
    if (fd < 0) {
        perror("Connect failed");
        return 1;
    }

    std::string input;
    std::cout << "Enter text to send:" << std::endl;
    while (std::getline(std::cin, input)) {
        write(fd, input.c_str(), input.size());
        std::cout << "Sent to server." << std::endl;
        break; // Single transaction for demo
    }

    close(fd);
    return 0;
}

Common Pitfalls and Verification

Understanding IPC nuances prevents deadlocks and resource leaks.

Technical Review Points

1. FD Inheritance: When calling fork, the new child inherits duplicate file descriptors pointing to the same underlying file description (including the kernel offset/buffer state).
2. Close Behavior: Always close unused ends of the pipe immediately after fork. If a parent keeps the write end open, a reader never sees EOF.
3. Memory Safety: Using snprintf instead of direct string copies mitigates buffer overflow risks during transmission.
4. Portability: System V IPC differs in semantics from POSIX; prefer POSIX interfaces for modern applications.