প্রসেস ও IPC — এক প্রোগ্রাম কীভাবে আরেকটির জন্ম দেয়, আর তারা কীভাবে কথা বলে

১ · প্রোগ্রাম আর প্রসেস — রেসিপি বনাম রান্না

আপনার ফোনে এখন কয়টি অ্যাপ খোলা? Facebook, bKash, YouTube, হয়তো একটি গেমও। সবগুলো একসাথে চলছে, কেউ কারো মেমরিতে হাত দিচ্ছে না, একটি crash করলে বাকিগুলো দিব্যি চলতে থাকে। এর পেছনে যে ধারণাটি কাজ করছে, তার নাম process. এই পর্বে আমরা সেটিই খুলে দেখব।

প্রথমে একটি পার্থক্য পরিষ্কার করি। প্রোগ্রাম হলো ডিস্কে রাখা একটি ফাইল — যেমন আপনার compile করা hello বা /bin/ls. এটি চুপচাপ পড়ে থাকে, কিছুই করে না। আপনি যখন সেটি চালান, তখন অপারেটিং সিস্টেম ফাইলটিকে মেমরিতে আনে, একটি stack ও heap বানিয়ে দেয়, CPU-র সময় বরাদ্দ করে — আর তখনই তৈরি হয় একটি প্রসেস। প্রসেস মানে চলমান অবস্থায় থাকা প্রোগ্রাম।

ঠিক তেমনি, আপনি যদি তিনটি terminal খুলে তিনবার একই প্রোগ্রাম চালান, তাহলে তিনটি আলাদা প্রসেস তৈরি হবে। প্রতিটি প্রসেস অপারেটিং সিস্টেমের কাছ থেকে কয়েকটি জিনিস পায়:

এই সবকিছুর হিসাব রাখে অপারেটিং সিস্টেম, আরও নির্দিষ্ট করে বললে তার ভেতরের kernel. Kernel হলো গার্মেন্টস কারখানার প্রোডাকশন ম্যানেজারের মতো — কোন লাইন কখন মেশিন পাবে, কে কতটা কাপড় নেবে, কেউ অন্যের টেবিলে হাত দিচ্ছে কি না, সব তাঁর নজরে। এক মুহূর্তে CPU-র একটি কোরে একটিই প্রসেস চলে; kernel সেকেন্ডে বহুবার প্রসেস বদলায় বলে মনে হয় সব একসাথে চলছে।

আপনার কম্পিউটারে এখন কী কী প্রসেস চলছে, নিজেই দেখতে পারেন। Windows-এ Task Manager খুলে “Details” ট্যাবে PID কলাম দেখুন। Linux বা Mac-এ terminal-এ লিখুন:

ps -ef          # সব প্রসেসের তালিকা, PID ও PPID সহ
pstree -p       # কে কার parent — গাছের আকারে
echo $$         # এই shell-এর নিজের PID

UID    PID   PPID  CMD
root     1      0  /sbin/init
rafi   500      1  -bash
rafi   812    500  vim notes.c
rafi   813    500  ps -ef          ← ps নিজেও একটি প্রসেস, তার parent হলো bash

আপনি terminal-এ যা-ই চালান, shell সেটির parent হয়। কীভাবে, সেটাই এই পর্বের মূল গল্প।

২ · System call — kernel-এর দরজায় কড়া নাড়া

একটি প্রশ্ন ভাবুন: আপনার প্রোগ্রাম যদি নিজের ইচ্ছামতো যেকোনো মেমরিতে লিখতে পারত, ডিস্কের যেকোনো জায়গা মুছতে পারত — তাহলে একটি ভুল প্রোগ্রাম বা একটি ভাইরাস পুরো কম্পিউটার নষ্ট করে দিত। তাই আধুনিক CPU দুটি আলাদা অধিকারের স্তরে চলে।

ব্যাংকে গিয়ে আপনি নিজে ভল্টে ঢুকে টাকা তুলতে পারেন না। কাউন্টারে একটি চেক জমা দেন, কর্মকর্তা ভেতরে গিয়ে কাজটি করে দেন। প্রোগ্রামের জগতে এই চেকের নামই system call, আর kernel-এর কাছে যাওয়ার এটিই একমাত্র বৈধ পথ। আপনি যখন printf ডাকেন, C library শেষ পর্যন্ত write নামের একটি system call করে — CPU তখন অল্প সময়ের জন্য kernel space-এ যায়, kernel লেখাটি স্ক্রিনে পাঠায়, তারপর আবার আপনার প্রোগ্রামে ফিরে আসে।

এখানে একটি কথা স্পষ্ট করে রাখি: এই পর্বের কোড POSIX মান অনুযায়ী — Linux, macOS, Android ও অন্যান্য Unix-ধাঁচের সিস্টেমে চলে। Windows-এ এগুলো সরাসরি নেই; সেখানে WSL (Windows Subsystem for Linux) বা এই পাতার অনলাইন রানার ব্যবহার করুন। পাতার রানারটি Linux-এ চলে, তাই নিচের কোডগুলো এখানেই চালাতে পারবেন।

৩ · fork() — একটি প্রসেস থেকে দুটি

এবার Unix-এর সবচেয়ে বিখ্যাত, আর প্রথম দেখায় সবচেয়ে অদ্ভুত ফাংশনটি। fork() ডাকলে kernel আপনার চলমান প্রসেসের একটি প্রায় হুবহু কপি তৈরি করে — একই কোড, ভ্যারিয়েবলের একই মান, একই খোলা ফাইল, এমনকি প্রোগ্রাম ঠিক কোন লাইনে আছে সেটিও একই। পার্থক্য শুধু PID-তে, আর fork()-এর ফেরত মানে।

একই কোড দুই প্রসেসে চলছে — তাহলে তারা আলাদা কাজ করে কীভাবে? ফেরত মান দেখে। if (pid == 0) হলে আমি child, না হলে parent. নিচের ডায়াগ্রামে একটি ছোট প্রোগ্রাম ধাপে ধাপে চালিয়ে দেখুন। ডান পাশে দুই প্রসেসের অবস্থা খেয়াল করুন:

1int main(void) {2    printf("Before fork: only one process\n");3    fflush(stdout);4    pid_t pid = fork();5    if (pid == 0) {           /* child */6        printf("Child: ...\n");7        exit(7);8    }9    waitpid(pid, &status, 0); /* parent */10    printf("Parent: ... %d\n", WEXITSTATUS(status));11}

পুরো মেমরি কি সত্যিই কপি হয়? — Copy-on-write

একটি প্রসেস যদি ২ GB মেমরি ব্যবহার করে, প্রতিবার fork-এ ২ GB কপি করা তো ভয়াবহ ধীর হতো! বাস্তবে kernel একটি চতুর কৌশল ব্যবহার করে, নাম copy-on-write. Fork-এর সময় আসল মেমরি কপি হয় না; শুধু “কোন ঠিকানা কোন RAM-পাতায়” সেই মানচিত্রটি কপি হয়, আর দুই প্রসেস একই পাতাগুলো ভাগ করে নেয়। পাতাগুলো “শুধু পড়া যাবে” চিহ্নিত থাকে। কেউ কোনো পাতায় লিখতে গেলেই একটি page fault হয়, kernel তখন কেবল সেই একটি পাতার আলাদা কপি বানিয়ে দেয়।

এবার নিজে চালিয়ে দেখুন। প্রোগ্রামটি fork করে, child একটি লাইন ছাপে আর exit(7) দিয়ে শেষ হয়, parent অপেক্ষা করে exit status পড়ে:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    printf("Before fork: only one process\n");
    fflush(stdout);                  /* empty the buffer before cloning */
    pid_t pid = fork();
    if (pid < 0) { perror("fork"); return 1; }
    if (pid == 0) {                  /* child: fork() returned 0 */
        printf("Child: fork() gave me 0, I will exit with 7\n");
        exit(7);
    }
    int status;                      /* parent: fork() returned child's PID */
    waitpid(pid, &status, 0);        /* wait until the child is finished */
    if (WIFEXITED(status))
        printf("Parent: child exited with status %d\n", WEXITSTATUS(status));
    return 0;
}

৪ · exec — একই প্রসেসে নতুন প্রোগ্রাম

fork দিয়ে আমরা নিজেরই একটি কপি পেলাম। কিন্তু shell-এ ls লিখলে তো bash-এর কপি চলে না, চলে ls প্রোগ্রাম! এর জন্য লাগে দ্বিতীয় অস্ত্র — exec পরিবার। exec চলমান প্রসেসের ভেতরের কোড, ডেটা, heap, stack সব ফেলে দিয়ে ডিস্ক থেকে নতুন একটি প্রোগ্রাম এনে বসায়, তারপর সেটির main থেকে চালানো শুরু করে।

exec-এর কয়েকটি রূপ আছে, নামের অক্ষর দেখেই চেনা যায়। সবগুলো শেষ পর্যন্ত একটিই system call ডাকে — execve.

নিচে fork আর exec একসাথে — shell-এর মূল কাজের ছোট একটি রূপ। এটি পড়ার জন্য; চালানোর দরকার নেই, পরের ডায়াগ্রামেই এর প্রতিটি ধাপ দেখবেন:

pid_t pid = fork();
if (pid == 0) {                              /* child */
    char *argv[] = { "ls", "-l", NULL };
    execvp("ls", argv);                      /* success: never returns */
    perror("execvp");                        /* reached only on failure */
    _exit(127);                              /* 127 = "command not found" */
}
int status;
waitpid(pid, &status, 0);                    /* parent waits, like a shell */

খেয়াল করুন execvp-এর পরের দুটি লাইন। exec সফল হলে এগুলো কখনো চলবে না। চলবে কেবল তখনই, যখন প্রোগ্রামটি খুঁজে পাওয়া যায়নি বা চালানোর অনুমতি নেই। এই লাইন দুটি না থাকলে ব্যর্থ child নিচে নেমে parent-এর কোড চালাতে শুরু করবে — তখন একই কাজ দুই প্রসেসে দুবার হবে। AI-এর লেখা কোডে এই ভুল প্রায়ই দেখা যায়।

এবার দেখুন আপনি terminal-এ ls -l লিখে Enter চাপলে shell ভেতরে ঠিক কী করে:

PID   PPID  প্রোগ্রাম   অবস্থা
500   1     bash       আপনার লেখা লাইন পড়ছে: "ls -l"

PID   PPID  প্রোগ্রাম   অবস্থা
500   1     bash       waitpid(501)-এ অপেক্ষা
501   500   bash       সবে জন্ম, fork() ফেরত দিল 0

PID   PPID  প্রোগ্রাম   অবস্থা
500   1     bash       waitpid(501)-এ অপেক্ষা
501   500   ls         bash-এর কোড মুছে /bin/ls বসেছে

-rw-r--r-- 1 rafi rafi  220 notes.txt
-rw-r--r-- 1 rafi rafi 1450 report.c
← ls শেষ, exit status 0; kernel bash-কে জাগাল

$ echo $?
0
$ ← পরের কমান্ডের অপেক্ষা

অন্য পথ — posix_spawn আর Windows-এর CreateProcess

Fork-এর পর প্রায় সাথে সাথেই exec — অর্থাৎ যে মেমরির মানচিত্র কপি করা হলো, তা প্রায় সাথে সাথেই ফেলে দেওয়া হচ্ছে। এই অপচয় এড়াতে POSIX মানে আছে posix_spawn(), যা এক ডাকেই নতুন প্রোগ্রাম চালু করে। Windows-এর মূল প্রোগ্রামিং ব্যবস্থা কখনো fork-এর পথে যায়নি; সেখানে CreateProcess() একটি ফাংশন কলেই প্রোগ্রামের নাম, argument, কোন ফাইল খোলা থাকবে ইত্যাদি সব প্যারামিটার নিয়ে নতুন প্রসেস তৈরি করে। কোন নকশা ভালো, সেই বিতর্ক ভাবনার প্রশ্নে।

৫ · wait, exit status — আর zombie ও orphan প্রসেস

পর্ব ০৪-এ দেখেছিলেন main-এর return 0 আসলে অপারেটিং সিস্টেমকে একটি সংখ্যা জানায় — exit status. সেই সংখ্যাটি কে পড়ে? উত্তর: parent, waitpid() দিয়ে। Shell-এ make && ./app লিখলে দ্বিতীয় কমান্ডটি তখনই চলে, যখন প্রথমটির exit status 0 — অর্থাৎ পুরো ব্যবস্থাটি এই ছোট সংখ্যার ওপর দাঁড়িয়ে।

এবার একটি গুরুত্বপূর্ণ প্রশ্ন: child শেষ হয়ে গেল, কিন্তু parent যদি কখনো waitpid না ডাকে? Kernel তো জানে না parent কখন ফল চাইবে, তাই child-এর exit status ফেলে দিতে পারে না। তখন child-এর মেমরি মুক্ত হয়, কিন্তু process table-এ তার একটি ছোট এন্ট্রি থেকে যায়। এই আধামরা অবস্থার নাম zombie process. উল্টোটাও ঘটে — child চলছে, কিন্তু parent আগেই শেষ হয়ে গেল। তখন child হয় orphan process. নিচে দুটিই দেখুন:

  PID  PPID STAT CMD
  700   500 S    ./server
  701   700 S    ./server   ← child, একটি কাজ করছে

  PID  PPID STAT CMD
  700   500 S    ./server
  701   700 Z    [server] <defunct>   ← zombie: exit status 3 জমা

  PID  PPID STAT CMD
  700   500 S    ./server
  701   700 Z    [server] <defunct>
  702   700 Z    [server] <defunct>
  703   700 Z    [server] <defunct>
  … হাজারো এন্ট্রি জমলে নতুন প্রসেস তৈরিই বন্ধ

  PID  PPID STAT CMD
  700   500 S    ./server   ← সব status সংগ্রহ করা হলো
  (701, 702, 703 — তালিকা থেকে মুছে গেছে)

  PID  PPID STAT CMD
    1     0 S    /sbin/init
  704     1 S    ./server   ← অনাথ, এখন PPID = 1

৬ · IPC ও pipe — প্রসেসেরা কীভাবে কথা বলে

এখন একটি সমস্যা দেখুন। Fork-এর পর parent যদি একটি global ভ্যারিয়েবল count = 5 করে, child কি সেটি দেখবে? না! Copy-on-write-এর কারণে parent লিখতেই তার জন্য নতুন পাতা তৈরি হয়েছে; child-এর কপিতে মান আগের মতোই। প্রসেসের নিজস্ব মেমরি — এই দেয়ালটিই নিরাপত্তার ভিত্তি, কিন্তু একই দেয়াল কথা বলাও কঠিন করে দেয়। তাই প্রসেসের মধ্যে তথ্য আদান-প্রদানের জন্য kernel কিছু বিশেষ পথ দেয়, যাদের একসাথে বলে IPC (Inter-Process Communication).

সবচেয়ে পুরোনো ও সরল পথটি হলো pipe. pipe(fd) ডাকলে kernel নিজের মেমরিতে একটি ছোট buffer বানায় (Linux-এ সাধারণত ৬৪ KB) আর আপনাকে দুটি file descriptor দেয়: fd[0] দিয়ে পড়া যায়, fd[1] দিয়ে লেখা যায়। এক মুখে যা ঢালবেন, অন্য মুখে সেটাই একই ক্রমে বের হবে।

ওই শেষ কথাটিই pipe-এর সবচেয়ে বড় নিয়ম। পড়ার দিক EOF পায় শুধু তখন, যখন pipe-এর লেখার মুখ যতগুলো প্রসেসে খোলা আছে, সব বন্ধ হয়। Fork-এর পর দুই প্রসেসের হাতেই দুই মুখ থাকে। তাই প্রত্যেককে নিজের অপ্রয়োজনীয় মুখটি বন্ধ করতে হয়। নিচের কোডে child লেখে, parent পড়ে:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
int main(void) {
    int fd[2];                       /* fd[0] = read end, fd[1] = write end */
    if (pipe(fd) == -1) { perror("pipe"); return 1; }
    pid_t pid = fork();
    if (pid < 0) { perror("fork"); return 1; }
    if (pid == 0) {                  /* child = writer */
        close(fd[0]);                /* child does not read */
        const char msg[] = "Salam from the child";
        if (write(fd[1], msg, sizeof msg - 1) < 0) _exit(1);
        close(fd[1]); _exit(0);      /* last write end closed: reader gets EOF */
    }
    close(fd[1]);                    /* parent does not write */
    char buf[64], c; int len = 0;
    while (len < 63 && read(fd[0], &c, 1) == 1) buf[len++] = c;
    buf[len] = '\0';
    close(fd[0]); waitpid(pid, NULL, 0);
    printf("Parent got %d bytes: \"%s\"\n", len, buf);
    return 0;
}

dup2 — shell-এর আসল জাদু

পর্ব ১০-এ আপনি ls | grep txt বা ./app > out.txt-এর মতো কমান্ড দেখেছেন। কিন্তু ls তো pipe-এর কথা কিছুই জানে না — সে শুধু fd 1-এ লেখে! তাহলে লেখা pipe-এ যায় কীভাবে? এখানেই dup2(). dup2(p[1], 1) মানে “fd 1 নম্বরটি এখন থেকে pipe-এর লেখার মুখের দিকে নির্দেশ করবে।” fork আর exec-এর মাঝখানে child এটি করে নেয়। আর যেহেতু exec খোলা file descriptor মুছে দেয় না, নতুন প্রোগ্রামটি না জেনেই pipe-এ লিখতে থাকে। নিচে প্রতিটি প্রসেসের file descriptor তালিকা ধাপে ধাপে দেখুন:

1/* shell: ls | grep txt */2pipe(p);              /* p[0]=3, p[1]=4 */3fork(); fork();       /* two children */4child1: dup2(4, 1); close(3); close(4);5        execlp("ls", ...);6child2: dup2(3, 0); close(3); close(4);7        execlp("grep", "grep", "txt", ...);8shell:  close(3); close(4);9        waitpid(...); waitpid(...);

৭ · আরও IPC — signal, shared memory, message queue, socket

Pipe সরল ও নির্ভরযোগ্য, কিন্তু সব কাজের জন্য উপযুক্ত নয়। এটি একমুখী, সাধারণত শুধু একই পরিবারের (fork-সম্পর্কিত) প্রসেসের মধ্যে চলে, আর প্রতিটি বাইট দুবার কপি হয় — পাঠানোর প্রসেস থেকে kernel-এ, kernel থেকে গ্রহণকারী প্রসেসে। তাই আরও কয়েকটি পথ আছে:

৮ · একটি mini-shell-এর নকশা, আর বাস্তব জগতে প্রসেস

এতক্ষণ যা শিখলেন, তা জুড়লেই একটি কাজ চালানোর মতো shell তৈরি হয়ে যায়। মূল লুপটি মাত্র কয়েকটি ধাপের:

চিরকাল:
    prompt দেখাও ("$ ")
    এক লাইন পড়ো                  ← fgets; EOF হলে লুপ শেষ
    লাইনকে শব্দে ভাঙো              ← "ls" "-l" NULL
    "cd" বা "exit" হলে নিজেই করো    ← built-in: child-এ করলে কাজ হবে না!
    pid = fork()
    child হলে:  execvp(শব্দ[0], শব্দ);  ব্যর্থ হলে _exit(127)
    parent হলে: waitpid(pid, &status, 0);  status মনে রাখো

একটি মজার প্রশ্ন: cd কেন আলাদা? কারণ বর্তমান ফোল্ডার প্রতিটি প্রসেসের নিজস্ব সম্পত্তি। Child-এ cd করলে শুধু child-এর ফোল্ডার বদলাবে, আর child শেষ হলে সেই পরিবর্তনও হারিয়ে যাবে — shell যেখানে ছিল সেখানেই থাকবে। তাই cd shell-কে নিজের প্রসেসেই করতে হয়। প্রসেসের দেয়াল কতটা বাস্তব, এটি তার সুন্দর প্রমাণ। এর সাথে pipe ও dup2 যোগ করলে |, >, < সবই সম্ভব — অনুশীলনের শেষ প্রশ্নটি এটি নিয়েই।

বাস্তব জগতে প্রসেসের ব্যবহার

খেয়াল করুন, চারটি উদাহরণেই একই নীতি: আলাদা প্রসেস মানে আলাদা দেয়াল। ভুল, crash বা আক্রমণ এক প্রসেসে আটকে থাকে। দাম হলো বেশি মেমরি আর IPC-র খরচ।

৯ · AI-এর যুগে প্রসেস-কোড — যেখানে AI সবচেয়ে বেশি ভুল করে

AI-কে “fork দিয়ে একটি প্রোগ্রাম লেখো” বললে সাধারণত এমন কোড আসে, যা প্রথমবার চালালে ঠিকঠাক দেখায়। সমস্যা ধরা পড়ে পরে — সার্ভার এক সপ্তাহ চলার পর, বড় ইনপুটে, বা কেউ অদ্ভুত ইনপুট দিলে।

শেষ ভুলটি সবচেয়ে বিপজ্জনক, তাই আলাদা করে দেখি। ধরুন AI একটি “ping টুল” লিখে দিল:

snprintf(cmd, sizeof cmd, "ping -c 1 %s", host);   /* host এসেছে ব্যবহারকারীর কাছ থেকে */
system(cmd);
ব্যবহারকারী লিখল:  8.8.8.8; rm -rf ~/projects

system() আসলে /bin/sh -c চালায়, আর shell-এর কাছে ; মানে “এরপর আরেকটি কমান্ড।” ফলে ping-এর পর ব্যবহারকারীর ফোল্ডার মুছে যাবে! এটি ওয়েবসাইটের ফর্মে থাকলে আক্রমণকারী আপনার সার্ভারেই কমান্ড চালাবে। সমাধান: shell একেবারে বাদ দিন — fork + execvp("ping", argv), যেখানে ইনপুট argv-র একটি আলাদা ঘরে বসে, ফলে ; শুধু একটি সাধারণ অক্ষর। সাথে ইনপুট যাচাই করুন (শুধু অঙ্ক আর বিন্দু)। বিস্তারিত পাবেন Cybersecurity কোর্সে।

AI-এর লেখা প্রসেস-কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি fork()-এর ফল তিন ভাগে দেখা হয়েছে: < 0, == 0, > 0
• Child-এর প্রতিটি পথ exec বা _exit-এ শেষ হয় — parent-এর কোডে গড়িয়ে পড়ে না
• প্রতিটি child-এর জন্য কোথাও একটি waitpid আছে
• Fork-এর পর প্রতিটি প্রসেস pipe-এর অপ্রয়োজনীয় মুখ বন্ধ করেছে, আর কাজ শেষে নিজের মুখও
• Fork-এর আগে fflush(stdout) আছে; আউটপুট ফাইলে পাঠিয়ে দ্বিগুণ লেখা নেই দেখেছি
• বাইরের ইনপুট কখনো system() বা popen()-এর কমান্ড-স্ট্রিংয়ে বসেনি