fork, exec, wait — যে function দুইবার return করে

দুটোই ছাপাবে: x = 11।

child: x = 11
parent: x = 11

(ক্রম নির্ধারিত নয় — scheduler ঠিক করে কে আগে চলবে।)

কারণ: fork()-এর মুহূর্তে x-এর মান (10) child-এ কপি হয়ে যায় (logically — বাস্তবে COW-এর মাধ্যমে)। এরপর দুই process সম্পূর্ণ স্বাধীন, একে অপরের memory-কে প্রভাবিত করে না।

x = x + 1 লাইনটা দুইবার চলে — একবার parent-এ, একবার child-এ, প্রতিটা তার নিজস্ব কপির উপর। কোনো race condition নেই, কারণ দুইটা আলাদা physical memory (COW fault-এর পরে)।

তুলনা করুন threading-এর সাথে (গত-গত লেসন):

int x = 10;
/* যদি এখানে fork()-এর বদলে pthread_create() হতো */
x = x + 1;   /* দুইটা thread-ই একই x শেয়ার করত — race condition! */

Thread-এ একই memory শেয়ার হয়, তাই x = x + 1 একটা read-modify- write যা দুই thread একসাথে করলে একটা increment হারিয়ে যেতে পারে (Level 4-এর synchronization লেসনে এই ক্লাসিক bug-টা বিস্তারিত)। Process-এ সেই সমস্যা নেই, কারণ address space আলাদা — এটাই process-based আর thread-based concurrency-র একটা মৌলিক নিরাপত্তা পার্থক্য।

ডিজাইনের যুক্তি — child-এর নিজের PID জানার জন্য 0-এর দরকার নেই, কারণ সেটা getpid() দিয়েই পাওয়া যায়:

pid_t pid = fork();
if (pid == 0) {
    printf("আমার PID: %d\n", getpid());   /* এখানে জানা যায় */
}

fork()-এর return value-র আসল কাজ ভিন্ন — কোন branch-এ আছি সেটা বলা, PID জানানো নয়। আর 0 এই কাজে বিশেষভাবে উপযুক্ত, কারণ:

১. 0 কখনো একটা বৈধ PID নয়। PID শুরু হয় 1 থেকে (init/systemd)। তাই 0 একটা sentinel value হিসেবে নিরাপদ — কোনো বিভ্রান্তির সুযোগ নেই যে “child-এর PID আসলেই 0 কি না” ভাবতে হবে।

২. দুইটা ভিন্ন তথ্য, দুইটা ভিন্ন query।

Parent-এর fork()-এর return value (child-এর PID) parent-এর জন্য দরকারি — সে পরে waitpid(child_pid, ...) ডাকবে, বা সেই child-কে signal পাঠাবে। Child-এর নিজের এই তথ্যটার দরকারই নেই, কারণ সে নিজেই সেই PID — getpid() তাকে সরাসরি দেয়।

৩. এক function, দুই ভূমিকা, দুই ধরনের প্রয়োজনীয় তথ্য — আর fork() সেই দুই তথ্যই ঠিক ঠিক জায়গায় দিয়ে দেয়:

pid_t pid = fork();
/* parent পায়:  child-এর PID (তাকে নিয়ন্ত্রণ করতে) */
/* child পায়:   0 (branch চেনার জন্য, নিজের PID না — সেটা getpid()-এ) */

এটা একটা elegant নকশা — একটামাত্র return value দিয়ে দুইটা ভিন্ন প্রশ্নের ঠিক ততটুকু উত্তর দেওয়া যতটা প্রতিটা branch-এর আসলেই দরকার।

সুবিধা — isolation বিনামূল্যে (প্রায়):

প্রতিটা connection সম্পূর্ণ আলাদা address space-এ চলে। একটা connection handler crash করলে (segfault, out-of-memory) — শুধু সেই একটা process মরে, বাকি সব connection অক্ষত। এই নকশায় memory corruption bug (buffer overflow, use-after-free) অন্য connection-এর ডেটা দূষিত করতে পারে না — কারণ physically আলাদা memory।

Thread-based মডেলে একই process-এর সব thread memory শেয়ার করে (লেসন ৬), তাই একটা corruption bug potentially সব connection-কে প্রভাবিত করতে পারে।

অসুবিধা — খরচ ও জটিলতা:

COW কীভাবে সাহায্য করে: fork()-এর পরপরই child সাধারণত শুধু পড়ে (request পার্স, response পাঠানো) — তাই অনেক page কখনো লেখা হয় না, COW-এর কারণে সেগুলো parent-এর সাথে শেয়ার্ড থেকে যায়। এটাই কারণ prefork model বাস্তবে যতটা ব্যয়বহুল মনে হয় ততটা নয়।

কখন এটা যুক্তিসঙ্গত:

• নিরাপত্তা-সংবেদনশীল কাজ — একটা connection-এর buffer overflow যেন অন্য user-এর session/memory ছুঁতে না পারে (privilege separation-এর একটা রূপ)
• তৃতীয়-পক্ষের/অবিশ্বস্ত কোড চালানো — CGI script, plugin
• মাঝারি concurrency (কয়েকশো-কয়েক হাজার connection, লক্ষ নয়)
• Crash isolation অগ্রাধিকার, throughput নয়

কখন যুক্তিসঙ্গত নয়:

• খুব বেশি concurrent connection (C10K+ সমস্যা — লেসন ২০-এ বিস্তারিত, যেখানে thread-per-connection-ও ভেঙে পড়ে আর event-driven মডেল লাগে)
• Connection-গুলোর মধ্যে ঘন ঘন শেয়ার্ড state দরকার (cache, connection pool) — তখন IPC-র overhead জেতার চেয়ে thread-এর স্বাভাবিক শেয়ারিং ভালো

বাস্তব বিশ্বে: আধুনিক high-throughput সার্ভার (nginx, node.js) এই দুইটার কোনোটাই ব্যবহার করে না প্রধান মডেল হিসেবে — তারা event-driven, single-threaded per worker (epoll-ভিত্তিক, লেসন ২০)। কয়েকটা worker process (fork-ভিত্তিক isolation-এর জন্য), প্রতিটা হাজার হাজার connection সামলায় non-blocking I/O দিয়ে — দুইটা জগতের ভালো দিক মেলানো।

Bug — এটা ৫টা worker তৈরি করে না, বরং একটা exponential বিস্ফোরণ ঘটায়।

সমস্যা: fork() parent আর child দুটোতেই loop চালিয়ে যায়, কারণ শুধু child-এ _exit(0) করা হচ্ছে — কিন্তু parent কোনো break বা early-exit ছাড়াই লুপ চালিয়ে যাচ্ছে, আর সেই parent-ও পরের iteration-এ আবার fork() ডাকছে।

ট্রেস করে দেখি:

iteration 0: মূল process fork করে → 2 process (1 parent + 1 child, child exit)
             বাকি থাকে: 1 (মূল process)

iteration 1: মূল process আবার fork করে → child exit করে,
             কিন্তু parent থেকে যায়

...আসলে সমস্যাটা আরো গভীর — প্রতিটা "বেঁচে থাকা" process-ই
পরের iteration-এ আবার fork করে, তাই:

i=0: 1 process → fork → 2 (1 exits) → 1 বেঁচে থাকে
i=1: সেই 1 → fork → 2 (1 exits) → 1 বেঁচে থাকে

আসলে এই নির্দিষ্ট কোডে exponential বিস্ফোরণ ঘটে না — কারণ প্রতিবার child সাথে সাথে _exit করছে, আর মূল process-ই (যেটা pid != 0 পেয়েছে) একাই পরের iteration-এ যাচ্ছে।

প্রকৃত bug ভিন্ন, আর সূক্ষ্ম: প্রতিটা fork()-এ parent process child-এর জন্য কখনো wait() ডাকে না। তাই প্রতিটা child শেষ হয়ে zombie হয়ে যায়, আর সেগুলো sleep(10)-এর পুরোটা সময় ধরে জমা থাকে — ৫টা zombie।

gcc -o buggy buggy.c && ./buggy &
sleep 1
ps -o pid,ppid,stat,comm --ppid $!

৫টা Z state entry দেখা যাবে।

ঠিক করা:

pid_t children[5];
for (int i = 0; i < 5; i++) {
    pid_t pid = fork();
    if (pid == 0) {
        printf("worker %d, PID %d\n", i, getpid());
        _exit(0);
    }
    children[i] = pid;       /* শুধু parent-এ এটা রাখা হয়, child-এ কখনো পৌঁছায় না */
}
for (int i = 0; i < 5; i++)
    waitpid(children[i], NULL, 0);

একটা দ্বিতীয় সূক্ষ্ম বিপদ যা এখানে নেই কিন্তু সহজেই ঘটতে পারত: যদি if (pid == 0)-এর ভেতরে _exit(0) না থেকে return 0 বা কিছুই না থাকত, তাহলে child-ও loop-এর বাকি অংশ চালিয়ে যেত — অর্থাৎ child নিজেও আবার fork() ডাকত! সেটাই প্রকৃত exponential বিস্ফোরণ ঘটাত: i=0-এ ২টা process (1 fork করে), i=1-এ প্রতিটা আবার fork করে ৪টা, i=2-এ ৮টা… i=4-এ ৩২টা process। এটাই একটা ছোট fork bomb-এর গঠন, আর _exit(0) (বা loop থেকে break) ভুলে যাওয়াই এর কারণ।

সাধারণ নিয়ম: fork()-এর child branch-এ সবসময় একটা স্পষ্ট _exit() বা exec() দিয়ে শেষ করুন, যাতে child কখনো ভুল করে বাকি কোড চালিয়ে না যায়।

শেয়ার্ড — এটা একটা গুরুত্বপূর্ণ সূক্ষ্মতা যা file-descriptor লেসনে (লেসন ১৬) বিস্তারিত আসবে, কিন্তু এখানেই প্রথম দেখা দরকার।

মনে করুন file descriptor-এর তিন-স্তরের indirection: fd table → open file description (offset + flag এখানে) → inode।

fork()-এ কপি হয় শুধু fd table-এর entry — অর্থাৎ parent আর child-এর fd number (যেমন 3) একই open file description-কে নির্দেশ করে।

int fd = open("log.txt", O_WRONLY | O_APPEND);
pid_t pid = fork();

if (pid == 0) {
    write(fd, "child\n", 6);   /* offset বাড়ায় */
    _exit(0);
}
waitpid(pid, NULL, 0);
write(fd, "parent\n", 7);      /* child-এর offset বৃদ্ধির পরে থেকে লেখে */

ফলাফল: ফাইলে child\nparent\n — দুইটা write সংঘর্ষ না করে পরপর বসেছে, কারণ offset শেয়ার্ড ছিল। যদি এটা দুইটা স্বতন্ত্র open() কল হতো (দুই আলাদা open file description), দুটোই offset 0-এ শুরু করত আর একে অপরকে overwrite করতে পারত।

এটা কেন গুরুত্বপূর্ণ — একটা বাস্তব ব্যবহার:

Web server-এর log file-এ multiple worker process লেখে। যদি প্রতিটা worker আলাদাভাবে open(..., O_APPEND) করে, O_APPEND প্রতিটা write-কে atomically ফাইলের শেষে বসায় (kernel-স্তরে guaranteed) — কিন্তু যদি একটা মাস্টার process file খুলে fork করে সব worker-এ fd শেয়ার করে, তাহলে offset-ও শেয়ার্ড থাকে, যা কিছু ব্যবহারে আরো predictable আচরণ দেয়।

তুলনা করুন dup()-এর সাথে:

int fd1 = open("f", O_RDONLY);
int fd2 = dup(fd1);       /* একই process-এ — offset শেয়ার্ড */

/* বনাম */

int fd3 = open("f", O_RDONLY);
int fd4 = open("f", O_RDONLY);  /* দুইটা আলাদা open — offset আলাদা */

fork()-এর fd কপি ঠিক dup()-এর মতো আচরণ করে — নতুন fd number, কিন্তু একই underlying open file description। এই সংযোগটা মনে রাখলে লেসন ১৬-এর তিন-স্তরের diagram সহজেই বোধগম্য হবে।