signal আর low-level I/O — file descriptor, poll আর mmap

১ · printf-এর নিচে কী আছে — file descriptor আর “সবকিছুই ফাইল”

পর্ব ২৪-এ আপনি fopen, fprintf, fclose দিয়ে ফাইলে লিখেছেন। পর্ব ৫০-এ দেখেছেন, printf শেষ পর্যন্ত write নামের একটি system call করে। এই পর্বে আমরা সেই তলায় নামব — যেখানে C library নেই, আছে শুধু আপনার প্রোগ্রাম আর kernel. একে বলে low-level I/O.

ফাইল, কিবোর্ড, স্ক্রিন, pipe, নেটওয়ার্ক সংযোগ — সম্পূর্ণ আলাদা জিনিস, তবু UNIX-এ সবগুলো একই চারটি ফাংশন দিয়ে ব্যবহার করা যায়: open, read, write, close. কীভাবে?

এই সংখ্যাটিই file descriptor (সংক্ষেপে fd). প্রতিটি প্রসেসের জন্য kernel একটি file descriptor table রাখে। তালিকার প্রতিটি ঘরের নম্বর একটি fd, আর ঘরটি নির্দেশ করে kernel-এর ভেতরের কোনো খোলা ফাইল, pipe বা socket-এর দিকে। প্রোগ্রাম চালু হওয়ার সময়েই তিনটি ঘর ভরা থাকে:

তাহলে FILE* কী? এটি C library-র বানানো একটি struct, যার ভেতরে আছে একটি fd আর একটি buffer. fprintf লেখা জমায় buffer-এ, আর buffer ভরলে একবারে write(fd, …) ডাকে। অর্থাৎ stdio হলো system call-এর ওপর বসানো একটি সুবিধার স্তর:

এই পর্বের কোড POSIX মান অনুযায়ী — Linux, macOS ও অন্যান্য Unix-ধাঁচের সিস্টেমে চলে; পাতার রানারও Linux-এ চলে। Windows-এর কথা অংশ ৮-এর শেষে।

২ · open, read, write, close — byte সরানোর চারটি system call

open — টোকেন নেওয়া

open দুটি বা তিনটি জিনিস নেয়: ফাইলের নাম, কী করতে চান তা জানানোর flag, আর নতুন ফাইল তৈরি হলে তার অনুমতি। সফল হলে ফেরত দেয় একটি fd — সবসময় সবচেয়ে ছোট খালি নম্বরটি। তাই 0, 1, 2 ভরা থাকলে প্রথম open সাধারণত 3 দেয়। ব্যর্থ হলে ফেরত দেয় -1, আর কারণটি রাখে errno-তে।

তৃতীয় argument 0644 হলো নতুন ফাইলের অনুমতি, octal-এ লেখা (শুরুর 0 খেয়াল করুন)। তিনটি অঙ্ক তিন দলের জন্য — মালিক, গ্রুপ, অন্য সবাই। ৬ মানে পড়া + লেখা, ৪ মানে শুধু পড়া। তবে আসল অনুমতি থেকে প্রসেসের umask কিছু বিট কেটে দেয়; সাধারণ umask 022 হলে 0666 চাইলেও ফাইল হয় 0644. O_CREAT দিয়ে এই argument বাদ দেওয়া একটি পরিচিত বাগ — তখন অনুমতি হয় register বা stack-এ পড়ে থাকা আবর্জনা মান।

ভুল হলে — errno, perror আর strerror

পর্ব ৩০-এ দেখেছেন, ব্যর্থ ফাংশন কারণের কোড রেখে যায় errno-তে। System call-এর জগতে এই কোডগুলোই আপনার প্রধান তথ্য। perror সেটিকে মানুষের ভাষায় stderr-এ ছাপে, আর strerror একটি string ফেরত দেয়। রানারে যাচাই করা কয়েকটি আসল মেসেজ:

open("missing.txt", O_RDONLY)  → -1, errno = ENOENT
open missing.txt: No such file or directory      ← perror("open missing.txt")
open("/etc/shadow", O_RDONLY)  → -1, errno = EACCES: Permission denied

read আর write — “কম পেলে ভুল নয়”

read(fd, buf, 100)-এর তিন রকম ফল হতে পারে, আর তিনটিই আলাদাভাবে সামলাতে হয়:

write-ও একই রকম। ডিস্ক ভরে গেলে, pipe-এর buffer ভরা থাকলে বা signal এলে সে চাওয়ার চেয়ে কম byte লিখে ফেরত আসতে পারে। সাধারণ ফাইলে এটি কালেভদ্রে ঘটে, কিন্তু pipe আর socket-এ খুবই স্বাভাবিক — তাই পেশাদার কোডে একটি “পুরোটা লেখো” ফাংশন থাকে। নিচের প্রোগ্রামটি একটি ছোট log ফাইল লেখে, তারপর ৮ byte-এর buffer দিয়ে পড়ে স্ক্রিনে (fd 1) কপি করে — অর্থাৎ একটি ক্ষুদ্র log copier:

#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
static int write_all(int fd, const char *p, size_t n) {
    while (n > 0) {                          /* write() may take only a part */
        ssize_t w = write(fd, p, n);
        if (w < 0) { if (errno == EINTR) continue; return -1; }
        p += w; n -= (size_t)w;
    }
    return 0;
}
int main(void) {
    int fd = open("app.log", O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (fd < 0) { perror("open"); return 1; }
    write_all(fd, "boot ok\nlogin rahim\ndisk 91%\n", 29); close(fd);
    if ((fd = open("app.log", O_RDONLY)) < 0) { perror("open"); return 1; }
    printf("log opened as fd %d\n", fd); fflush(stdout);   /* empty stdio's buffer first */
    char buf[8]; ssize_t n; int calls = 0;
    while ((n = read(fd, buf, sizeof buf)) > 0) { write_all(1, buf, (size_t)n); calls++; }
    close(fd); printf("read() calls: %d\n", calls);
}

close, fd leak আর lseek

প্রতিটি fd kernel-এর একটি সম্পদ আটকে রাখে, আর প্রসেস একসাথে কতগুলো খুলে রাখতে পারবে তার সীমা আছে — অনেক Linux সিস্টেমে ডিফল্ট ১০২৪ (ulimit -n দিয়ে দেখুন)। সার্ভার প্রতিটি অনুরোধে একটি ফাইল খুলে বন্ধ করতে ভুলে গেলে, এক সময় সব open ব্যর্থ হবে EMFILE নিয়ে — এর নাম fd leak. Linux-এ কোনো প্রসেসের খোলা fd গুনতে ls /proc/<pid>/fd বা lsof -p <pid> দেখুন।

আরেকটি সূক্ষ্ম জায়গা: exec-এর পরেও fd খোলা থাকে (পর্ব ৫০-এ এভাবেই pipe জোড়া হয়েছিল), তাই অপ্রয়োজনীয় fd — যেমন একটি database সংযোগ — নতুন প্রোগ্রামের হাতে চলে যেতে পারে। এজন্য O_CLOEXEC (close-on-exec) দিয়ে খোলা ভালো অভ্যাস।

lseek হলো fseek-এর low-level রূপ। lseek(fd, 0, SEEK_END) অবস্থানকে ফাইলের শেষে নিয়ে নতুন অবস্থান ফেরত দেয় — অর্থাৎ ফাইলের আকার। Pipe বা socket-এ lseek চলে না (ESPIPE), কারণ স্রোতকে পেছনে টানা যায় না।

৩ · dup2 আর buffering — shell-এর > আর উল্টো ক্রমের রহস্য

পর্ব ৫০-এ ls | grep txt-এর ভেতরে dup2 দেখেছেন। একই কৌশলে shell ./app > out.txt করে, যাকে বলে redirection. এবার fd তালিকার ভেতরে কী হয়, একটি প্রসেসের দিক থেকে ধাপে ধাপে দেখুন:

1/* shell's child, before exec */2int fd = open("out.txt", O_WRONLY|O_CREAT|O_TRUNC, 0644);3dup2(fd, 1);       /* fd 1 now = out.txt */4close(fd);         /* 3 no longer needed */5execlp("./app", "./app", (char *)NULL);6/* inside app: printf -> write(1, ...) */

dup(fd) হলো এর সরল ভাই — একই খোলা ফাইলের একটি নতুন নম্বর দেয়। প্রোগ্রামের ভেতরে কিছুক্ষণের জন্য stdout ঘুরিয়ে আবার ফেরাতে চাইলে saved = dup(1) করে রাখুন, কাজ শেষে dup2(saved, 1).

printf আর write — কেন উল্টো ক্রমে আসে

এবার অংশ ২-এর রহস্য। printf সাথে সাথে write ডাকে না; stdio-র buffer-এ জমায় (পর্ব ১০ ও ২৪)। কখন পাঠাবে, তা নির্ভর করে stdout কোথায় যুক্ত তার ওপর:

এখন log copier-এর ঘটনাটি পরিষ্কার। রানারে stdout একটি pipe, তাই printf("log opened…") buffer-এ বসে রইল। অথচ write(1, …) buffer এড়িয়ে সরাসরি kernel-এ গেল। ফলে পরে লেখা জিনিস আগে পৌঁছাল, আর printf-এর দুটি লাইন একসাথে বেরোল প্রোগ্রামের শেষে। Terminal-এ চালালে line-buffering-এর কারণে ক্রম ঠিক দেখাত। নিয়ম: একই fd-তে stdio আর raw write মেশালে, সীমানায় fflush দিন — অথবা যেকোনো একটিই ব্যবহার করুন।

৪ · Signal — অপারেটিং সিস্টেমের হঠাৎ টোকা

এবার উল্টো দিক: কখনো kernel নিজেই প্রোগ্রামকে থামিয়ে কিছু জানাতে চায় — ব্যবহারকারী Ctrl+C চেপেছেন, একটি child শেষ হয়েছে, প্রোগ্রাম নিষিদ্ধ মেমরিতে হাত দিয়েছে, বা বেঁধে দেওয়া সময় শেষ। এই বার্তার নাম signal.

প্রতিটি signal-এর একটি নাম আর নম্বর আছে। Handler না বসালে প্রতিটি signal-এ প্রসেস একটি default action নেয় — বন্ধ হওয়া, বন্ধ হয়ে core dump রেখে যাওয়া, উপেক্ষা করা, বা থেমে থাকা। সবচেয়ে কাজের signal-গুলো (নম্বরগুলো Linux-এর; অন্য সিস্টেমে কয়েকটি আলাদা):

রানারে strsignal() দিয়ে এগুলোর বর্ণনা ছাপলে আসে Interrupt, Terminated, Alarm clock, Segmentation fault — সেই চেনা মেসেজগুলো, যা shell মৃত প্রোগ্রামের পরে দেখায়। Shell-এ কোনো প্রোগ্রাম signal-এ মারা গেলে তার exit status হয় ১২৮ + signal নম্বর; তাই Ctrl+C-তে মরা প্রোগ্রামের পর echo $? দেখায় 130.

Ctrl+C চাপার পর আসলে কী কী ঘটে? ধরুন একটি প্রোগ্রাম কিবোর্ড থেকে লাইন পড়ছে, আর SIGINT-এর জন্য একটি handler বসানো আছে (কীভাবে বসায়, পরের অংশে)। ধাপে ধাপে দেখুন:

1static volatile sig_atomic_t stop = 0;2void on_int(int s) { stop = 1; }3int main(void) {  /* sigaction(SIGINT): no SA_RESTART */4    while (!stop) {5        n = read(0, line, sizeof line);6        if (n < 0 && errno == EINTR) continue;7        handle(line, n);8    }9    save_and_close(); return 0;10}

৫ · sigaction আর async-signal-safety — handler-এ কী করা যায়, কী যায় না

পর্ব ২৮-এ function pointer শেখার সময় signal(SIGINT, on_ctrl_c) দেখেছিলেন — সবচেয়ে সরল উপায়। কিন্তু পেশাদার কোডে signal() প্রায় ব্যবহারই হয় না। কারণটি ইতিহাসে।

সেই বিভ্রান্তি আজও আছে। Linux-এর glibc সাধারণত signal()-কে BSD-ধাঁচে চালায় (handler থেকে যায়, system call আবার শুরু হয়)। কিন্তু gcc -std=c11-এর মতো কড়া মোডে compile করলে সেই একই signal() পুরোনো System V আচরণে চলে — handler একবারেই শেষ! sigaction-এ এই অনিশ্চয়তা নেই; আপনি নিজে সব বলে দেন:

SA_RESTART দিলে signal-এ বাধা পাওয়া read/write-এর মতো system call kernel নিজেই আবার শুরু করে — EINTR নিয়ে মাথা ঘামাতে হয় না। কিন্তু আগের stepper-এ দেখলেন, তাতে মূল লুপ flag দেখার সুযোগ হারায়। আর Linux-এ poll, select, epoll_wait, nanosleep-এর মতো কিছু ডাক SA_RESTART থাকলেও কখনো আবার শুরু হয় না, সবসময় EINTR দেয়। তাই EINTR সামলানোর কোড রাখতেই হয়।

Handler-এর ভেতরে — সবচেয়ে কড়া নিয়ম

Signal আসে যেকোনো মুহূর্তে। ধরুন মূল প্রোগ্রাম printf-এর ভেতরে, stdout-এর buffer-এ অর্ধেক লেখা কপি করেছে, buffer-এর lock ধরে আছে। ঠিক তখন signal এলো, আর handler-এও printf. Handler সেই একই buffer ছুঁতে গেল — হয় lock-এর জন্য চিরকাল অপেক্ষা (deadlock), নয়তো অর্ধেক-বদলানো buffer আরও এলোমেলো। malloc-এরও একই সমস্যা: heap-এর তালিকা অর্ধেক বদলানো অবস্থায় handler আবার malloc ডাকলে heap নষ্ট হয়ে যায় (পর্ব ৪৭-এ দেখেছেন allocator-এর ভেতরে কী জটিল তালিকা থাকে)।

তাই POSIX একটি তালিকা দিয়েছে: যেসব ফাংশন handler-এর ভেতর থেকে ডাকা নিরাপদ, তারা async-signal-safe. তালিকায় আছে write, read, _exit, close, kill, waitpid, sigaction ইত্যাদি। তালিকায় নেই printf, fprintf, malloc, free, exit (সে stdio flush করে), strerror-এর মতো বহু পরিচিত ফাংশন।

Flag-এর টাইপ হয় volatile sig_atomic_t. volatile (পর্ব ৪৫) compiler-কে বলে, “এই মান লুকিয়ে বদলাতে পারে, প্রতিবার মেমরি থেকে পড়ো” — নইলে optimizer while (!stop)-কে চিরকালের লুপ বানিয়ে ফেলতে পারে। আর sig_atomic_t নিশ্চিত করে যে মানটি এক ধাক্কায় লেখা হয়, অর্ধেক লেখা অবস্থায় কেউ দেখবে না। নিচের প্রোগ্রামে দুটি ঘটনাই দেখুন — Ctrl+C (raise দিয়ে নিজেকেই SIGINT পাঠিয়ে), আর একটি watchdog timer, যা আটকে থাকা read-কে ১ সেকেন্ড পর ভেঙে দেয়:

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <signal.h>
#include <unistd.h>
static volatile sig_atomic_t got = 0;
static void on_sig(int sig) { got = sig; }            /* handler only sets a flag */
int main(void) {
    struct sigaction sa = {0};
    sa.sa_handler = on_sig; sigemptyset(&sa.sa_mask);  /* sa_flags = 0: no SA_RESTART */
    sigaction(SIGINT, &sa, NULL); sigaction(SIGALRM, &sa, NULL);
    for (int job = 1; got == 0; job++) {
        printf("job %d done\n", job);
        if (job == 3) raise(SIGINT);                   /* as if Ctrl+C was pressed */
    }
    printf("got signal %d: saving work, closing files\n", (int)got);
    int p[2]; char c; if (pipe(p) == -1) return 1;     /* nobody writes to p[1] */
    alarm(1);                                          /* watchdog: SIGALRM in 1 s */
    ssize_t n = read(p[0], &c, 1);                     /* blocks... until the alarm */
    printf("read returned %zd (%s), signal %d\n", n, strerror(errno), (int)got);
    return 0;
}

Signal আটকে রাখা — sigprocmask

কখনো কোডের একটি অংশ এমন, যেখানে signal-এ বাধা পাওয়া চলবে না — যেমন দুটি সম্পর্কিত হিসাব একসাথে বদলানো। তখন sigprocmask(SIG_BLOCK, &set, &old) দিয়ে signal আটকে রাখুন, কাজ শেষে sigprocmask(SIG_SETMASK, &old, NULL). আটকানো signal হারায় না; প্রসেসের signal mask-এ থাকা অবস্থায় অপেক্ষা করে, ছাড়লেই পৌঁছায়। তবে একই signal অপেক্ষার সময় দশবার এলেও সাধারণত একবারই পৌঁছায় — সাধারণ signal গোনা যায় না, শুধু “অন্তত একবার এসেছে” বোঝা যায়। (Multithreaded প্রোগ্রামে একই কাজ করে pthread_sigmask — পর্ব ৫২.)

৬ · বাস্তবের signal-নকশা — গুছিয়ে বন্ধ হওয়া, SIGCHLD আর SIGPIPE

Graceful shutdown — SIGTERM থেকে পরিষ্কার বিদায়

একটি বাস্তব দৃশ্য: আপনার bKash-এর মতো একটি লেনদেন সার্ভার Docker container-এ চলছে। নতুন version deploy করতে docker stop দেওয়া হলো। Docker প্রথমে প্রোগ্রামকে SIGTERM পাঠায়, তারপর ডিফল্টে ১০ সেকেন্ড অপেক্ষা করে; এর মধ্যে বন্ধ না হলে SIGKILL. Kubernetes-এও একই নকশা, ডিফল্ট অপেক্ষা ৩০ সেকেন্ড। প্রোগ্রাম SIGTERM না ধরলে মাঝপথের লেনদেন অর্ধেক হয়ে থাকবে। ধরলে সে graceful shutdown করতে পারে:

sigaction(SIGTERM, on_term)       ← handler: stop = 1, আর কিছু না
sigaction(SIGINT,  on_term)
while (!stop):
    নতুন অনুরোধ নাও, কাজ করো    ← poll/read EINTR দিলে লুপের শুরুতে ফেরো
নতুন অনুরোধ নেওয়া বন্ধ করো         ← listening socket close
চলমান লেনদেনগুলো শেষ করো           ← সময়সীমার মধ্যে
buffer flush, ফাইল ও সংযোগ বন্ধ, অস্থায়ী ফাইল মোছো
exit(0)

বড় সার্ভারগুলো signal-কে নিয়ন্ত্রণের ভাষা হিসেবেও ব্যবহার করে — যেমন nginx SIGHUP পেলে বন্ধ না হয়ে configuration আবার পড়ে।

SIGCHLD — zombie পরিষ্কারের ঘণ্টা

পর্ব ৫০-এ নিয়ম শিখেছেন: “যে fork করে, সে-ই wait করে।” কিন্তু একটি সার্ভার তো waitpid-এ বসে থাকতে পারে না — তাকে নতুন সংযোগ নিতে হবে। সমাধান: child শেষ হলেই kernel parent-কে SIGCHLD পাঠায়। Handler (বা handler-এর flag দেখে মূল লুপ) তখন যত child শেষ হয়েছে সবাইকে তুলে নেয়:

while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
    /* একটি child reaped — দরকার হলে তার status লিখে রাখুন */
}

এখানে দুটি সূক্ষ্মতা। লুপ কেন? কারণ তিনটি child প্রায় একসাথে মরলে SIGCHLD হয়তো একবারই পৌঁছাবে — signal গোনা যায় না, তাই একবারে সবাইকে তুলতে হয়। WNOHANG কেন? যাতে আর কোনো মৃত child না থাকলে waitpid অপেক্ষা না করে সাথে সাথে 0 ফেরত দেয়। waitpid async-signal-safe, তাই handler-এর ভেতরেও এটি চলে। আর child-এর ফলাফল একদমই না লাগলে SIGCHLD-কে SIG_IGN করলে Linux-এ child শেষ হয়েই মুছে যায়, zombie হয় না।

SIGPIPE — নিঃশব্দ মৃত্যু

পর্ব ৫০-এ দেখেছেন, pipe-এর পড়ার দিক বন্ধ হলে লেখার আর কোনো অর্থ নেই। Kernel তখন লেখককে SIGPIPE পাঠায়, আর ডিফল্টে প্রোগ্রাম কোনো মেসেজ ছাড়াই মারা যায়। yes | head -1-এ এটিই কাম্য, কিন্তু সার্ভারে একজন client হঠাৎ সংযোগ কাটলেই পুরো সার্ভার মারা যাওয়া — বিপর্যয়। রানারে দুটি অবস্থাই যাচাই করা:

/* পড়ার দিক বন্ধ pipe-এ write — default action */
child killed by signal: 1, sig=13
/* signal(SIGPIPE, SIG_IGN) দেওয়ার পর একই write */
write = -1, errno = Broken pipe, EPIPE? 1

নিয়ম: সার্ভার বা নেটওয়ার্ক প্রোগ্রামে শুরুতেই SIGPIPE উপেক্ষা করুন (SIG_IGN), আর প্রতিটি write-এর পর EPIPE দেখে শুধু সেই সংযোগটি বন্ধ করুন। Socket-এ বিকল্প হলো পর্ব ৫৩-এর send(…, MSG_NOSIGNAL).

Signal-কে সাধারণ ঘটনা বানানো — self-pipe আর signalfd

Handler-এর সীমাবদ্ধতা এড়ানোর সবচেয়ে পরিষ্কার উপায় হলো signal-কে একটি file descriptor-এর ঘটনায় রূপ দেওয়া। Self-pipe trick-এ প্রোগ্রাম নিজের জন্য একটি pipe বানায়; handler শুধু তাতে write(pfd[1], "x", 1) করে (write async-signal-safe). মূল লুপ সেই pipe-এর পড়ার মুখটিকে অন্য socket-এর সাথে poll-এ দেখে — signal এলে সেটি “পড়ার মতো ডেটা এসেছে” হয়ে ধরা পড়ে। Linux এর জন্য সরাসরি একটি system call দেয়: signalfd, যা কিছু signal আটকে রেখে সেগুলোর জন্য একটি fd ফেরত দেয়; handler-ই লাগে না।

৭ · poll — এক thread, অনেক দরজা

একটি চ্যাট প্রোগ্রামের কথা ভাবুন। তাকে একসাথে দুটি জায়গা দেখতে হবে: কিবোর্ড (আপনি কিছু লিখলেন কি না) আর নেটওয়ার্ক (বন্ধু কিছু পাঠাল কি না)। read(0, …) ডাকলে কিবোর্ডে কিছু না আসা পর্যন্ত প্রোগ্রাম ঘুমিয়ে থাকবে — এর মধ্যে বন্ধুর বার্তা এলেও দেখবে না। একটি read একটিই দরজায় দাঁড়াতে পারে।

O_NONBLOCK — অপেক্ষা না করা

কোনো fd-তে O_NONBLOCK দিলে (open-এ, বা পরে fcntl দিয়ে) সেটি হয় non-blocking: ডেটা না থাকলে read ঘুমায় না, সাথে সাথে -1 আর EAGAIN দেয় (রানারে খালি pipe-এ: Resource temporarily unavailable). শুধু এটুকু দিয়ে লুপে বারবার চেষ্টা করলে CPU ১০০% পুড়বে। এর আসল কাজ poll-এর সাথে জুটি বেঁধে — poll বলে কখন চেষ্টা করতে হবে, non-blocking নিশ্চিত করে চেষ্টাটি আটকাবে না।

poll — কোন দরজায় কেউ এলো

poll-কে আপনি একটি তালিকা দেন: কোন কোন fd, প্রতিটিতে কিসের অপেক্ষা (POLLIN = পড়ার মতো কিছু এলো, POLLOUT = লেখার জায়গা আছে), আর সর্বোচ্চ কত মিলিসেকেন্ড অপেক্ষা। Kernel প্রসেসকে ঘুম পাড়ায়, আর যেকোনো একটি fd তৈরি হলেই জাগায়। ফেরত মান হলো কয়টি fd তৈরি; 0 মানে timeout, -1 মানে ভুল (প্রায়ই EINTR). কোনটি তৈরি, তা kernel লিখে দেয় প্রতিটি ঘরের revents-এ। নিচে দুটি pipe, যার শুধু দ্বিতীয়টিতে ডেটা আছে:

#include <stdio.h>
#include <poll.h>
#include <unistd.h>
int main(void) {
    int a[2], b[2];
    if (pipe(a) == -1 || pipe(b) == -1) return 1;
    if (write(b[1], "bKash: 500 tk", 13) != 13) return 1;   /* only pipe b has data */
    struct pollfd fds[2] = { { a[0], POLLIN, 0 }, { b[0], POLLIN, 0 } };
    int ready = poll(fds, 2, 1000);                  /* wait at most 1000 ms */
    printf("ready = %d\n", ready);
    for (int i = 0; i < 2; i++) {
        if (fds[i].revents & POLLIN) {
            char buf[32];
            ssize_t n = read(fds[i].fd, buf, sizeof buf - 1);
            if (n > 0) { buf[n] = '\0'; printf("pipe %d: %s\n", i, buf); }
        } else printf("pipe %d: nothing yet\n", i);
    }
    return 0;
}

প্রত্যাশিত আউটপুট (Linux-এ, এই পাতার রানারের মতো পরিবেশে যাচাই করা):
ready = 1
pipe 0: nothing yet
pipe 1: bKash: 500 tk

খেয়াল করুন, poll সাথে সাথে ফিরেছে — ১০০০ ms পুরো অপেক্ষা করেনি, কারণ একটি fd আগেই তৈরি ছিল। আর b[1] বন্ধ করে আবার poll করলে revents-এ আসে POLLHUP — অন্য প্রান্ত চলে গেছে। একটি বাস্তব event loop-এ এই কাজ চলে চিরকালের লুপে। ধাপে ধাপে দেখুন:

1struct pollfd fds[2] = {{a, POLLIN}, {b, POLLIN}};2for (;;) {3    int r = poll(fds, 2, 5000);4    if (r == 0) { puts("timeout"); continue; }5    for (i = 0; i < 2; i++) {6        if (fds[i].revents & POLLIN)  read_and_print(i);7        else if (fds[i].revents & POLLHUP) close_and_skip(i);8    }9}

select, poll, epoll — একই প্রশ্নের তিন প্রজন্ম

অনেক fd একসাথে দেখার এই কৌশলের নাম I/O multiplexing. এর তিনটি প্রধান রূপ আছে:

পর্ব ৫৩-এ দেখবেন, হাজারো client সামলানো server এই কারণেই epoll-ভিত্তিক event loop-এ চলে। একটি সূক্ষ্ম পার্থক্য: poll হলো level-triggered — fd তৈরি থাকলে প্রতিবার জানায়; epoll-এর edge-triggered মোডে একবারই জানায়, তাই সেখানে EAGAIN না আসা পর্যন্ত সব পড়ে ফেলতে হয়।

৮ · mmap — ফাইলকে মেমরির মতো পড়া

read দিয়ে ফাইল পড়লে byte দুবার নড়ে: ডিস্ক থেকে kernel-এর মেমরিতে, তারপর kernel থেকে আপনার buffer-এ। mmap একটি ভিন্ন প্রস্তাব দেয়: “ফাইলটিকেই আমার ঠিকানা-জগতে বসিয়ে দাও।” তারপর একটি সাধারণ char *p দিয়ে p[0], p[5000] পড়লেই ফাইলের সেই byte — কোনো read নেই, কোনো buffer নেই।

এটি সম্ভব হয় virtual memory-র জন্য (পর্ব ৫০ ও ৪৭)। প্রসেসের মেমরি পাতায় ভাগ করা — সাধারণ x86-64 Linux-এ প্রতিটি পাতা ৪০৯৬ byte (রানারে sysconf(_SC_PAGESIZE) দেখায় 4096). mmap প্রথমে কিছুই পড়ে না, শুধু হিসাব লিখে রাখে: “এই ঠিকানা থেকে ওই ফাইল।” পড়া হয় আলসেমি করে, পাতা ধরে ধরে:

ঠিকানা-জগৎ     পাতা ০ [0–4095]      পাতা ১ [4096–8191]    পাতা ২ [8192–11999]
অবস্থা         ফাঁকা (ফাইলের দিকে নির্দেশ)   ফাঁকা                ফাঁকা
RAM-এ এসেছে   ০টি পাতা         ← mmap সাথে সাথে ফেরত, কোনো disk-পড়া নেই

ঠিকানা-জগৎ     পাতা ০               পাতা ১                পাতা ২
অবস্থা         ফাইলের byte 0–4095   ফাঁকা                ফাঁকা
ঘটনা          CPU থামল → kernel পাতা ০ আনল (page cache থেকে, না থাকলে disk থেকে)
              → প্রোগ্রাম আবার চলল, c পেল

ঠিকানা-জগৎ     পাতা ০               পাতা ১                পাতা ২
অবস্থা         ফাইলের byte 0–4095   ফাঁকা                ফাইলের byte 8192–…
RAM-এ এসেছে   ২টি পাতা          ← পাতা ১ কখনো না ছুঁলে কখনো পড়াই হবে না

প্রসেস A  ──► পাতা ০ ─┐
                       ├──► page cache-এর একই পাতা (RAM-এ একটিই কপি)
প্রসেস B  ──► পাতা ০ ─┘
shared library (libc.so) সব প্রোগ্রামে ঠিক এভাবেই ভাগ হয়

ঠিকানা-জগৎ     (কিছু নেই)
p[10] পড়লে    Segmentation fault   ← ঝুলন্ত pointer, পর্ব ২০-এর use-after-free-এর মতো
page cache     পাতাগুলো হয়তো আরও কিছুক্ষণ RAM-এ থাকবে — পরের পাঠকের জন্য

এবার একটি বাস্তব কাজ: একটি বিক্রির ফাইলে কয়টি লাইন, mmap দিয়ে গোনা। fstat দিয়ে ফাইলের আকার জেনে পুরো ফাইল map করা হয়, তারপর সাধারণ লুপ:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main(void) {
    int fd = open("sales.txt", O_RDONLY);              /* "rice,2\noil,1\nsugar,3\n" */
    if (fd < 0) { perror("open"); return 1; }
    struct stat st;
    if (fstat(fd, &st) == -1) { perror("fstat"); return 1; }
    char *p = mmap(NULL, (size_t)st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
    if (p == MAP_FAILED) { perror("mmap"); return 1; }  /* NOT NULL! */
    close(fd);                                           /* the mapping stays valid */
    long lines = 0;
    for (off_t i = 0; i < st.st_size; i++) if (p[i] == '\n') lines++;
    printf("%ld bytes, %ld lines\n", (long)st.st_size, lines);
    munmap(p, (size_t)st.st_size);
    return 0;
}

প্রত্যাশিত আউটপুট (ফাইলে তিনটি লাইন থাকলে; Linux-এ যাচাই করা):
21 bytes, 3 lines
খালি ফাইলে (আকার 0) mmap ব্যর্থ হয়:
mmap: Invalid argument

তিনটি জিনিস খেয়াল করুন। এক, ব্যর্থ হলে mmap NULL নয়, MAP_FAILED ফেরত দেয় — AI প্রায়ই if (!p) লিখে ভুল করে। দুই, map করার পর fd বন্ধ করলেও ম্যাপিং টিকে থাকে। তিন, দৈর্ঘ্য 0 হলে mmap EINVAL দেয়, তাই খালি ফাইল আলাদা করে সামলাতে হয়।

Anonymous mapping — parent আর child-এর ভাগ করা খাতা

পর্ব ৫০-এ দেখেছেন, fork-এর পর parent আর child-এর মেমরি আলাদা — একজন লিখলে অন্যজন দেখে না। কিন্তু fork-এর আগে mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0) দিয়ে মেমরি নিলে, সেই অংশটি fork-এর পরেও দুজনের মধ্যে ভাগ করা থাকে। এটি anonymous mapping — কোনো ফাইল ছাড়া, শূন্যে ভরা shared memory. রানারে যাচাই: child *cnt = 99 লিখে বের হলো, আর parent waitpid-এর পর পড়ল parent sees 99. মনে রাখুন, দুজন একসাথে লিখলে পর্ব ৫২-এর race condition — শৃঙ্খলা নিজেকেই রাখতে হবে।

কখন mmap, কখন read?

mmap জাদুর গুলি নয় — প্রতিটি page fault-এর খরচ আছে। নিয়মটি পর্ব ৫৫-এর মতোই: অনুমান নয়, মেপে দেখুন।

Windows-এ কী হয়? — portability

এই পর্বের সবকিছু POSIX. Windows-এর নিজস্ব নকশা আছে, যা ধারণায় কাছাকাছি কিন্তু নামে ও খুঁটিনাটিতে আলাদা:

তাই portable প্রোগ্রাম হয় শুধু standard C-র stdio ব্যবহার করে, নয়তো libuv-এর মতো library, যা নিচে নিজেই epoll, kqueue বা IOCP বেছে নেয় (Node.js-এর ভেতরে এটিই আছে)।

৯ · AI-এর যুগে low-level কোড — যা একবার চালিয়ে ধরা পড়ে না

AI-এর লেখা signal বা I/O কোড আপনার মেশিনে একশোবার ঠিকঠাক চলতে পারে, কারণ এসব বাগ নির্ভর করে সময়ের ওপর — ধরা পড়ে সার্ভারে, ভিড়ের সময়।

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

• Handler-এ শুধু flag সেট করা (বা async-signal-safe ফাংশন); flag-এর টাইপ volatile sig_atomic_t
• sigaction ব্যবহার হয়েছে, sa_mask ও sa_flags স্পষ্ট; SA_RESTART-এর সিদ্ধান্ত বোঝা যায়
• প্রতিটি read/write-এ তিন রকম ফল (>0, 0, -1) আলাদাভাবে সামলানো; partial write-এর লুপ আছে
• প্রতিটি open-এর জোড়া close আছে — ভুলের পথেও; দরকার হলে O_CLOEXEC
• SIGPIPE উপেক্ষা করা হয়েছে, আর EPIPE হলে শুধু সেই সংযোগ বন্ধ হয়
• stdio আর raw write একই fd-তে মেশানো হলে সীমানায় fflush আছে; ./app > out.txt করে আউটপুটের ক্রম মিলিয়েছি
• strace -f ./app চালিয়ে system call-গুলো নিজের চোখে দেখেছি, আর kill -TERM দিয়ে বন্ধ হওয়ার পথ পরীক্ষা করেছি