Signal — process-কে asynchronous ভাবে বাধা দেওয়ার প্রোটোকল

Signal = process-স্তরের interrupt — সরাসরি তুলনা

সমান্তরালতাটা টেবিলে দেখলে পরিষ্কার হয়:

	Hardware interrupt (interrupts-and-drivers লেসন)	Signal
কে থামে	CPU (এক বা একাধিক core)	একটা নির্দিষ্ট process
কে থামায়	Device বা timer	kernel — hardware exception, অন্য process-এর kill(), বা kernel event-এর প্রতিক্রিয়ায়
রুটিং টেবিল	IDT/vector table — kernel-এর, পুরো সিস্টেমে একটাই	sigaction টেবিল — প্রতিটা process-এর নিজস্ব, task_struct-এ
Handler কোথায় চলে	ring 0, kernel code, IF flag ক্লিয়ার	ring 3, user code — process নিজে যা রেজিস্টার করেছে
Default disposition	নেই যদি vector খালি — crash	প্রতিটা signal-এর built-in kernel default (Term/Ign/Core/Stop/Cont)
মাস্ক করা যায়?	হ্যাঁ — IF flag, APIC mask register	হ্যাঁ — sigprocmask(), blocked set
সম্পূর্ণ বন্ধ করা যায়?	না শুধু NMI ছাড়া	না শুধু SIGKILL/SIGSTOP ছাড়া

এই সমান্তরালতা কাকতালীয় না। computer-architecture module-এর interrupts-exceptions-traps লেসনের রেফারেন্স তালিকায় একটা লাইন ছিল — “হার্ডওয়্যার exception কীভাবে POSIX signal-এ রূপান্তরিত হয়।” এখন সেটা সরাসরি দেখছি: একটা divide-by-zero, hardware-এ যেটা একটা #DE exception, kernel সেটা ধরে user process-কে SIGFPE পাঠায়। একটা invalid memory access — hardware-এ page fault, kernel-and-user-space লেসনের wall.c experiment-এ যা দেখেছিলাম — kernel সেটাকে SIGSEGV-তে রূপান্তরিত করে পাঠায়। hardware exception আর OS signal একই ঘটনার দুইটা ভিন্ন স্তরের নাম।

কিন্তু signal শুধু hardware exception থেকেই আসে না — এটা সফটওয়্যার থেকেও আসতে পারে:

উৎস	উদাহরণ
Hardware exception → kernel রূপান্তর	অবৈধ মেমরি → SIGSEGV, divide-by-zero → SIGFPE, illegal instruction → SIGILL
Terminal driver	Ctrl-C → SIGINT, Ctrl-Z → SIGTSTP, Ctrl-\ → SIGQUIT — foreground process group-এ পাঠানো হয়
kill() syscall (অন্য process থেকে)	kill(pid, SIGTERM), শেলের kill কমান্ড
Kernel event	child terminate/stop/continue → SIGCHLD, pipe-এর পড়ার প্রান্ত বন্ধ থাকতে write → SIGPIPE (pipes-and-fifos লেসনে দেখা)
Timer	alarm()/setitimer() মেয়াদ শেষ → SIGALRM
প্রোগ্রাম নিজে	raise(sig), abort() (→ SIGABRT)

Standard signal set — সংখ্যা আর নাম মুখস্থ করার মতো নয়, বোঝার মতো

Linux x86-64-এ kill -l চালালে এই তালিকা বেরোয় — প্রতিটা সংখ্যা স্থির, POSIX-নির্ধারিত (real-time রেঞ্জ ছাড়া):

 1) SIGHUP     2) SIGINT     3) SIGQUIT    4) SIGILL     5) SIGTRAP
 6) SIGABRT    7) SIGBUS     8) SIGFPE     9) SIGKILL   10) SIGUSR1
11) SIGSEGV   12) SIGUSR2   13) SIGPIPE   14) SIGALRM   15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD   18) SIGCONT   19) SIGSTOP   20) SIGTSTP
21) SIGTTIN   22) SIGTTOU   23) SIGURG    24) SIGXCPU   25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF   28) SIGWINCH  29) SIGIO     30) SIGPWR
31) SIGSYS   34) SIGRTMIN  ...  ...  ...              64) SIGRTMAX

এই লেসনের কেন্দ্রে যে ছয়টা:

#	নাম	ডিফল্ট action	মানে
2	SIGINT	Term	Interactive interrupt — Ctrl-C, “থামো, দয়া করে”
15	SIGTERM	Term	Terminate — kill কমান্ডের ডিফল্ট, “please exit”
9	SIGKILL	Term	Kill — কখনো catch/block/ignore করা যায় না
11	SIGSEGV	Core	Segmentation violation — অবৈধ মেমরি অ্যাক্সেস
17	SIGCHLD	Ign	Child status বদলেছে — terminate/stop/continue
19/18	SIGSTOP/SIGCONT	Stop/Cont	Job control — থামাও/আবার চালাও, SIGSTOP-ও un-catchable

পাঁচ রকম ডিফল্ট action

প্রতিটা signal-এর একটা kernel-নির্ধারিত ডিফল্ট আচরণ আছে, যদি প্রোগ্রাম নিজে কিছু না করে (handler রেজিস্টার না করে, SIG_IGN সেট না করে):

Action	কী ঘটে
Term	Process সাথে সাথে শেষ — কোনো core file না
Ign	কিছুই ঘটে না — signal-টা কার্যত অদৃশ্য
Core	Process শেষ, আর একটা core dump ফাইল লেখা হয় (debugging-এর জন্য, core বা core.<pid>)
Stop	Process থামে (T state), পরে SIGCONT না আসা পর্যন্ত চলবে না
Cont	থামা process আবার চলতে শুরু করে

কেন SIGKILL আর SIGSTOP কখনো catch করা যায় না

বাকি প্রতিটা signal-এর জন্য kernel delivery-র সময় sigaction টেবিল দেখে — process কি নিজের handler বসিয়েছে, নাকি SIG_IGN করেছে, নাকি ডিফল্ট চলবে। কিন্তু SIGKILL (9) আর SIGSTOP (19) — kernel-এর signal-delivery কোডে এই দুইটার জন্য আলাদা, hard-coded শর্টকাট আছে যা পুরো “sigaction টেবিল চেক করো” ধাপটাই বাদ দেয়। sigaction(SIGKILL, &sa, NULL) কল করলে সরাসরি EINVAL ফেরত আসে — kernel এমনকি চেষ্টাটাই প্রত্যাখ্যান করে।

এটা কোনো accident না, ইচ্ছাকৃত ডিজাইন। ভাবুন: একটা process buggy, তার সব signal handler নষ্ট বা deadlocked, বা সে ইচ্ছাকৃতভাবে সব signal block করে রেখেছে (sigprocmask() দিয়ে, নিচে বিস্তারিত)। যদি প্রতিটা signal handler-এর মধ্য দিয়ে যেতে হতো, তাহলে একটা truly-broken process-কে থামানোর কোনো গ্যারান্টিড উপায়ই থাকত না। SIGKILL সেই গ্যারান্টি — একটা escape hatch যেটা কখনো ব্যর্থ হয় না, কারণ এটা process-এর নিজের কোড চালানোর কোনো সুযোগই দেয় না। kernel সরাসরি scheduler/task-management স্তরে process-টাকে terminate-এর জন্য চিহ্নিত করে, runqueue থেকে সরায়, exit path চালায় — কোনো user-space instruction চলার সুযোগই নেই।

SIGSTOP একই কারণে un-catchable — job control (Ctrl-Z, debugger attach) নির্ভরযোগ্যভাবে কাজ করতে হলে “থামাও” নির্দেশটাও গ্যারান্টিড হতে হবে, নাহলে একটা buggy process নিজেকে থামানো থেকে আটকাতে পারত।

Custom handler — signal() বনাম sigaction()

সবচেয়ে পুরনো, সবচেয়ে সরল API:

void handler(int sig) {
    printf("পেলাম signal %d\n", sig);
}
signal(SIGINT, handler);

এটা দেখতে সহজ, কিন্তু ঐতিহাসিকভাবে সমস্যাযুক্ত। মূল Unix (System V) সংস্করণে signal()-এর semantics ছিল “unreliable” — একটা handler একবার চললেই তার disposition ডিফল্টে রিসেট হয়ে যেত (মানে handler-কে নিজেই আবার নিজেকে রেজিস্টার করতে হতো, আর সেই দুই কাজের মাঝে একটা race window থাকত যেখানে দ্বিতীয় signal ডিফল্ট action চালিয়ে দিত)। BSD একটা “reliable” সংস্করণ আনল, আর POSIX শেষমেশ sigaction()-কে প্রামাণ্য, portable API হিসেবে দাঁড় করাল।

struct sigaction {
    void     (*sa_handler)(int);                          /* সরল handler */
    void     (*sa_sigaction)(int, siginfo_t *, void *);    /* SA_SIGINFO হলে এটা */
    sigset_t   sa_mask;      /* handler চলাকালীন আর কোন signal block থাকবে */
    int        sa_flags;     /* SA_SIGINFO, SA_RESTART, ... */
};

আধুনিক কোডে সবসময় sigaction(), কারণ এটা স্পষ্ট, predictable semantics দেয়: disposition রিসেট হয় না (handler নিজেকে আবার বসাতে হয় না), আর ডিফল্টে sa_mask-এ যা দেওয়া হয় তা এবং handler যে signal-টার জন্য চলছে সেটাও handler চলাকালীন স্বয়ংক্রিয়ভাবে block থাকে — যাতে একই signal-এর দুইটা instance একে অপরের ভেতরে recursively ঢুকে না পড়ে।

struct sigaction sa = {0};
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGINT, &sa, NULL);

kill(), raise(), আর process group

kill(pid, SIGTERM);      /* pid-কে পাঠাও */
kill(0, SIGTERM);        /* নিজের process group-এর সবাইকে */
kill(-pgid, SIGTERM);    /* নির্দিষ্ট process group-এর সবাইকে -- ঋণাত্মক pid মানে group */
raise(SIGABRT);          /* নিজেকে -- kill(getpid(), sig)-এর সংক্ষিপ্ত রূপ */

শেলের Ctrl-C আসলে kill(-fg_pgid, SIGINT)-এর সমতুল্য — terminal driver পুরো foreground process group-কে পাঠায়, শুধু একটা process-কে না। এইজন্যই একটা pipeline (cmd1 | cmd2 | cmd3) চলাকালীন Ctrl-C চাপলে তিনটা process-ই একসাথে থামে।

Disposition fork()-এ বাঁচে, exec()-এ আংশিক হারায়

fork-exec-wait লেসনে fork() আর exec()-এর সম্পূর্ণ আচরণ দেখা হয়ে গেছে — এখন সেই একই দুইটা syscall signal-এর জন্য কী করে সেটা যোগ করা যাক, কারণ নিয়মটা প্রায়ই ভুল অনুমান করা হয়।

fork()-এ — child সম্পূর্ণ signal disposition টেবিলের একটা কপি পায়, ঠিক যেভাবে সে বাকি address space-এর copy-on-write কপি পায় (page-faults-and-demand-paging লেসন)। parent-এ যদি SIGTERM-এর জন্য একটা custom handler বসানো থাকে, child শুরুতে ঠিক সেই একই handler-ই পাবে। blocked/pending set-ও কপি হয় (pending অবশ্য child-এর জন্য খালি শুরু হয়, কারণ pending কোনো নির্দিষ্ট process-এর ইতিহাস, উত্তরাধিকার না)।

exec()-এ — এখানেই আসল সূক্ষ্মতা। exec() পুরো process image প্রতিস্থাপন করে (code, data, heap, stack — fork-exec-wait লেসনের সেই আলোচনা), তাই একটা পুরনো handler function-এর ঠিকানা আর অর্থবহ থাকে না — নতুন বাইনারিতে সেই ঠিকানায় হয়তো সম্পূর্ণ ভিন্ন কোড বসে আছে। তাই নিয়ম:

Disposition (exec-এর আগে)	exec-এর পরে
ডিফল্ট action	অপরিবর্তিত থাকে
SIG_IGN (ইচ্ছাকৃতভাবে ignore করা)	অপরিবর্তিত থাকে — ignore-ই থাকে
Custom handler function	ডিফল্টে রিসেট হয় — পুরনো handler ঠিকানা অর্থহীন

SIG_IGN কেন বেঁচে যায়, handler কেন যায় না — এটা ইচ্ছাকৃত: “আমি এই signal-এ পাত্তা দিই না” একটা নীতিগত সিদ্ধান্ত যা নতুন প্রোগ্রামেও অর্থবহ থাকতে পারে (যেমন শেল pipeline-এ SIGPIPE-কে ইচ্ছাকৃতভাবে ignore করে রাখা কিছু ক্ষেত্রে), কিন্তু একটা function pointer একটা সম্পূর্ণ ভিন্ন বাইনারিতে অর্থহীন — সেটা রাখলে exec()-করা প্রোগ্রাম random code address-এ jump করে ফেলতে পারত।

blocked set (sigprocmask()-এর মাধ্যমে যা সেট করা) exec()-এর পরেও বেঁচে থাকে — এটাই কারণ শেল-লেখকদের সাবধান থাকতে হয়: parent shell যদি ভুলবশত কোনো signal block করে রাখে আর সেটা exec()-এর আগে unblock না করে, child process (যেমন vim বা less) সেই signal-টা পুরোপুরি ব্লক অবস্থাতেই শুরু করবে, নিজে কিছু না জেনেই — একটা বাস্তব, প্রায়ই ভোগা bug class।

SIGCHLD — fork-exec-wait লেসনের সেই wait()-এর ঘটনার সম্পূর্ণ রূপ

fork-exec-wait লেসনে wait()/waitpid() দেখেছিলাম — parent সক্রিয়ভাবে জিজ্ঞেস করছিল “child কি শেষ হয়েছে?”, প্রয়োজনে ব্লক হয়ে বসে থেকে। কিন্তু একটা shell বা process supervisor সবসময় child-দের নিয়ে ব্যস্ত থাকতে চায় না — অন্য কাজ করতে চায়, আর child মরলে/থামলে/আবার চালু হলে খবর পেতে চায়। SIGCHLD ঠিক সেই খবর — child terminate, stop, বা continue করলে kernel parent-কে SIGCHLD পাঠায় (ডিফল্ট action Ign, তাই না ধরলে চুপচাপ কিছুই দৃশ্যমান হয় না, কিন্তু child তখনও reap করা দরকার, নাহলে zombie জমে — গত লেসনের সেই সমস্যা)।

idiomatic প্যাটার্ন handler-এ শুধু flag সেট না করে সরাসরি reap করারও প্রলোভন হতে পারে, কিন্তু সঠিক pattern-টা এরকম:

static volatile sig_atomic_t child_exited = 0;

static void sigchld_handler(int sig) {
    child_exited = 1;          /* handler-এ শুধু এটুকু -- waitpid() নিচে main loop-এ */
}

/* main loop-এ: */
if (child_exited) {
    child_exited = 0;
    int status;
    pid_t pid;
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        printf("child %d reaped\n", pid);
    }
}

WNOHANG-সহ loop-টা বাধ্যতামূলক, একবার wait() না — কারণটা নিচের “signal গোনে না” অংশে আসছে। এখানেই মূল বিন্দু: SIGCHLD handler নিজে waitpid() কল করাও ঠিক আছে (এটা POSIX-এ async-signal-safe, নিচের তালিকায় আছে), কিন্তু flag+main-loop প্যাটার্নটাই বেশি সাধারণ কারণ handler-এ যত কম কাজ, তত ভালো — সেই যুক্তিটাই এই লেসনের বাকি অংশ জুড়ে আসছে।

SIGSEGV — page-faults-and-demand-paging লেসনের decision tree-র সরাসরি ফলাফল

page-faults-and-demand-paging লেসনে page fault handler-এর একটা decision tree দেখেছিলাম:

১. ঠিকানা কোনো VMA-র ভেতরে?  না → SIGSEGV "invalid address"
২. VMA permission fault-এর ধরনকে অনুমতি দেয়?  না, COW-ও প্রযোজ্য না → SIGSEGV "protection violation"

এই দুইটা পথই SIGSEGV-তে গিয়ে শেষ হয় — kernel page fault handler থেকেই সরাসরি এই signal তৈরি হয়। kernel-and-user-space লেসনের wall.c experiment-এ যে si_code=1 (SEGV_MAPERR) দেখেছিলাম, সেটা ঠিক এই প্রথম case — NULL pointer dereference, কারণ ঠিকানা 0 কোনো VMA-র ভেতরেই নেই।

Handler-এর সবচেয়ে বিপজ্জনক অংশ — reentrancy

এখন লেসনের কেন্দ্রীয় সমস্যায় আসি। একটা handler function যেকোনো সাধারণ ফাংশনের মতোই দেখতে — কিন্তু একটা মৌলিক পার্থক্য আছে যা প্রায়ই ভুলে যাওয়া হয়: এটা আপনার প্রোগ্রামের মূল control flow-এর মাঝখানে, আক্ষরিক অর্থে যেকোনো instruction-এর ফাঁকে ঢুকে পড়তে পারে — কোনো ফাংশন কল-এর মাঝখানে, একটা struct আপডেটের মাঝখানে, এমনকি একটা library ফাংশনের ভেতরের কোনো lock/unlock-এর মাঝখানে।

এটা কংক্রিটভাবে দেখা যাক malloc() দিয়ে। fork-exec-wait লেসনে একটা সংশ্লিষ্ট bug দেখেছিলাম — threaded প্রোগ্রামে fork() করলে child-এ একটা arena lock “locked অবস্থায় জমে” যেতে পারে, কারণ যে thread সেটা release করত সে child-এ অস্তিত্বেই নেই। এখানে ঠিক একই root cause, ভিন্ন trigger:

মূল প্রোগ্রাম (main flow):          signal handler (হঠাৎ ঢুকে পড়ল):
  malloc(64) ডাকল
    arena lock নিল
    free-list-এর pointer আপডেট
    করছে -- অর্ধেক সম্পন্ন, তালিকা
    এই মুহূর্তে inconsistent
                                       [signal আসল, এই মুহূর্তেই]
                                       handler চলা শুরু করল
                                       handler ভেতরে log করতে
                                       malloc(32) ডাকল
                                         arena lock নেওয়ার চেষ্টা --
                                         কিন্তু lock-টা তো "locked"
                                         (মূল প্রোগ্রামের সেই
                                         অসমাপ্ত call-এর হাতে)
                                       --- চিরতরে আটকে গেল ---

glibc-র ptmalloc arena lock একটা সাধারণ non-recursive lock — কে ধরে আছে তার কোনো real “owner” ট্র্যাকিং নেই, শুধু locked/unlocked। handler যদি সেই একই thread-এ চলে (আর signal handler সবসময় সেই thread-এই চলে যাকে বাধাগ্রস্ত করেছে), আর সেই thread-ই lock-টা “আটকে বসে” আছে (কারণ তার call-টা মাঝপথে থেমে আছে, শেষ হয়নি) — তাহলে handler-এর malloc() কল একটা lock-এর জন্য অপেক্ষা করছে যেটা কখনো release হবে না, কারণ যে call সেটা release করত সে কখনো আবার চলার সুযোগই পাবে না (handler নিজেই আটকে আছে)। একটা perfect self-deadlock, একই thread-এর নিজের সাথে।

printf()-এর ভেতরেও ঠিক একই সমস্যা — এটা নিজেও internally malloc() (buffer allocation) আর একটা stdio lock ব্যবহার করে। এই ধরনের bug console-এ প্রায় কখনো ধরা পড়ে না — এটা মাসে একবার production-এ ঘটে, ঠিক তখন যখন signal-টা ঠিক সেই ন্যানোসেকেন্ড উইন্ডোয় এসে পড়ে যখন malloc() মাঝপথে ছিল — সবচেয়ে খারাপ, সবচেয়ে debug-করা-কঠিন সময়ে।

নিরাপদ প্যাটার্ন — flag সেট করো, বাকিটা main loop-এ

সমাধান সরল একটা নিয়মে নেমে আসে: handler-এ শুধু একটা flag সেট করো আর সাথে সাথে return করো। বাকি সব কাজ main loop-এ, normal execution context-এ করো, যেখানে malloc()/printf() ব্যবহার সম্পূর্ণ নিরাপদ।

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

static volatile sig_atomic_t got_signal = 0;

static void handler(int sig) {
    got_signal = 1;             /* শুধু এটুকু, আর কিছু না */
}

int main(void) {
    struct sigaction sa = {0};
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sigaction(SIGINT, &sa, NULL);

    while (!got_signal) {
        /* মূল কাজ -- এখানে malloc/printf/lock সব স্বাভাবিকভাবে ব্যবহার করা যায় */
    }
    printf("সিগন্যাল পেয়ে পরিষ্কারভাবে বের হচ্ছি\n");   /* এখানে printf() নিরাপদ -- handler-এ না */
    return 0;
}

volatile sig_atomic_t টাইপটা এখানে ইচ্ছাকৃত, দুইটা কারণে। sig_atomic_t নিশ্চিত করে read/write নিজেই atomic — কোনো torn write নেই (একটা long long বা struct-এর মাঝপথে handler ঢুকে পড়লে আধা-লেখা অবস্থা দেখতে পারত)। volatile কম্পাইলারকে বলে এই ভ্যারিয়েবলটা register-এ cache করে রাখা যাবে না — নাহলে compiler অপটিমাইজেশনে ধরে নিতে পারে while (!got_signal) কখনো বদলাবে না (কারণ loop-এর ভেতরে কোথাও এটাকে সরাসরি বদলাতে দেখছে না) আর পুরো লুপ-চেকটাই বাদ দিয়ে দিতে পারে।

Async-signal-safety — একটা নামকরণ করা, POSIX-নির্ধারিত ধারণা

উপরের সমস্যাটার একটা প্রামাণ্য নাম আছে। একটা ফাংশন async-signal-safe যদি POSIX গ্যারান্টি দেয় যে সেটা নিরাপদে signal handler-এর ভেতর থেকে ডাকা যায় — হয় কারণ এটা reentrant (কোনো shared mutable state/lock নেই), অথবা কারণ এটা signal-এর সাপেক্ষে atomic।

নিরাপদ (এই ধরনের একটা ছোট সেট)	অনিরাপদ (বাকি প্রায় সবকিছু)
_exit(), write(), read()	malloc(), free(), realloc()
signal(), sigaction(), sigprocmask()	printf()/fprintf()/sprintf() — পুরো stdio family
kill(), raise(), alarm(), pause()	strtok() — internal static state
fork(), execve(), _exit()	localtime()/gmtime() — static buffer রিটার্ন করে
waitpid()	qsort() — নিজে বিভিন্ন internal state ব্যবহার করতে পারে
sigemptyset()/sigaddset()/sigismember()	যেকোনো ফাংশন যা internally malloc() করে

sigprocmask() — signal block করা, একটা primitive critical-section রক্ষা

যদি main flow-এ এমন একটা অংশ থাকে যেখানে shared data (যেটা handler-ও ছুঁতে পারে) touch হচ্ছে, আর সেটা কোনোভাবে interrupted হলে সমস্যা — সরাসরি সমাধান হলো সেই সময়টুকুর জন্য signal-টা block করে রাখা:

sigset_t block_set, old_set;
sigemptyset(&block_set);
sigaddset(&block_set, SIGINT);

sigprocmask(SIG_BLOCK, &block_set, &old_set);   /* এখন থেকে SIGINT আটকানো */
/* critical section -- shared_data touch করা এখন নিরাপদ */
sigprocmask(SIG_SETMASK, &old_set, NULL);        /* আগের mask ফিরিয়ে আনো */

Block করা মানে signal হারিয়ে যায় না — এটা pending হয়ে থাকে (নিচের hood সেকশনে বিস্তারিত), আর unblock হওয়ার সাথে সাথে deliver হয়। ব্যতিক্রম শুধু SIGKILL/SIGSTOP — আগের সেকশনে দেখা সেই hard-coded শর্টকাটের কারণে এরা masking-কেও পুরোপুরি bypass করে।

মাল্টি-থ্রেডেড প্রোগ্রামে sigprocmask() না, pthread_sigmask() ব্যবহার করতে হয় — কারণ Linux-এ প্রতিটা thread-এর নিজস্ব blocked set আছে (যদিও pending set process-জুড়ে শেয়ার্ড), threads লেসনের সেই per-thread state-এর ধারণার সরাসরি সম্প্রসারণ।

EINTR — signal যখন একটা blocking syscall-কে মাঝপথে থামায়

একটা শেষ বাস্তব সমস্যা বাকি, যেটা build সেকশনের self-pipe কোডে ইতিমধ্যে একবার নীরবে ব্যবহার করা হয়েছে। ধরুন প্রোগ্রাম একটা “slow” syscall-এ ব্লক হয়ে বসে আছে — read() কোনো pipe থেকে ডেটার অপেক্ষায় (pipes-and-fifos লেসন), select()/accept() কোনো নতুন connection-এর অপেক্ষায়। ঠিক তখন একটা signal আসে, handler চলে, ফিরে আসে। সেই থেমে-থাকা syscall-টা এখন কী করবে — নিজে থেকে আবার অপেক্ষা চালিয়ে যাবে, নাকি থেমে যাবে?

উত্তরটা নির্ভর করে SA_RESTART flag-এর উপর, যা sigaction()-এর sa_flags-এ দেওয়া যায়:

SA_RESTART	Slow syscall-এর আচরণ
না দেওয়া (ডিফল্ট)	syscall সাথে সাথে -1 রিটার্ন করে, errno = EINTR — প্রোগ্রামকে নিজে চেক করে আবার কল করতে হয়
দেওয়া থাকলে	kernel নিজেই syscall-টা আবার শুরু করে, প্রোগ্রাম কিছুই টের পায় না

এটাই ঠিক সেই একই “unreliable বনাম reliable signal” ইতিহাসের আরেকটা মাত্রা — পুরনো System V-তে সব signal EINTR দিত (প্রোগ্রামারকে সবসময় manually retry-loop লিখতে হতো), BSD স্বয়ংক্রিয় restart চালু করল। POSIX উভয় বিকল্পই রাখল, SA_RESTART দিয়ে বেছে নেওয়ার সুযোগসহ — তবে সব syscall restart হয় না, select(), poll(), read() ছোট timeout-এর সাথে — এদের জন্য SA_RESTART থাকলেও প্রায়ই EINTR আসতে পারে, তাই সাবধানী কোড সবসময় EINTR চেক করে retry করে, SA_RESTART-এর উপর ভরসা না করে:

ssize_t n;
do {
    n = read(fd, buf, sizeof(buf));
} while (n == -1 && errno == EINTR);   /* signal-এ বাধাগ্রস্ত হলে আবার চেষ্টা */

build সেকশনের self-pipe কোডে if (ready < 0) continue; লাইনটা ঠিক এই কারণেই ছিল — select() signal-এ বাধাগ্রস্ত হয়ে EINTR-সহ ফিরলে, সেটাকে error না ধরে শুধু আবার loop-এর মাথায় ফিরে যাওয়া, কারণ ততক্ষণে আসল কাজটা (self-pipe-এ byte লেখা) ইতিমধ্যেই হয়ে গেছে হয়তো, পরের select() call-এই সেটা ধরা পড়বে।