একসাথে অনেক client — fork, thread আর thread pool সার্ভার

১ · একজন একজন করে — iterative সার্ভার আর তার সীমা

পর্ব ৪১-এ (TCP socket প্রোগ্রামিং) যে echo সার্ভার বানানো হয়েছে, তার মূল লুপ মোটামুটি এই: accept() দিয়ে একটি সংযোগ নেওয়া, সেই client-এর সব কাজ শেষ করা, সংযোগ বন্ধ করা, তারপর আবার accept(). এমন সার্ভারকে বলে iterative সার্ভার — এক সময়ে ঠিক একজন client. শেখার জন্য চমৎকার, কিন্তু বাস্তবে প্রায় কখনো যথেষ্ট নয়।

সময়ের হিসাব — কেন শেষজন সবচেয়ে বেশি ভোগে

ধরা যাক প্রতিটি request সামলাতে সার্ভারের সময় লাগে S, আর N জন client একই মুহূর্তে আসে। Iterative সার্ভারে i-তম client (i = ১, ২, …, N) উত্তর পায় i × S সময়ে, কারণ তাকে আগের i − ১ জনের পুরো কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয়। তাই:

• শেষ client-এর অপেক্ষা = N × S
• গড় অপেক্ষা = (S + 2S + … + NS) / N = S × N(N + 1) / (2N) = (N + 1) × S / 2
• Throughput = N / (N × S) = ১ / S — client যতই বাড়ুক, সেকেন্ডে সামলানো request বাড়ে না

উদাহরণ: S = ২০০ ms, N = ৪ হলে চারজন উত্তর পান ২০০, ৪০০, ৬০০ আর ৮০০ ms-এ; গড় (৪ + ১) × ২০০ / ২ = ৫০০ ms. একসাথে সামলানো গেলে প্রত্যেকে পেতেন ২০০ ms-এ। N = ১০০ হলে শেষজনের অপেক্ষা ২০ সেকেন্ড — ততক্ষণে অ্যাপ সাধারণত হাল ছেড়ে দেয়।

আসল সমস্যা আরও খারাপ: সার্ভারের সময়ের বেশিরভাগ যায় অপেক্ষায় — ধীর মোবাইল সংযোগের client-এর পরের বাইট, ডেটাবেসের উত্তর, ডিস্ক। তখন CPU প্রায় অলস, অথচ iterative সার্ভার read()-এ আটকে থাকে। কেউ সংযোগ খুলে কিছুই না পাঠালে সার্ভার চিরকাল অপেক্ষা করবে, বাকিরা kernel-এর accept queue-তে জমবে, আর queue (backlog) ভরলে নতুন SYN উপেক্ষিত হবে (পর্ব ২৯)। একটি ধীর client = পুরো সেবা বন্ধ।

২ · প্রতি সংযোগে একটি প্রসেস — fork() সার্ভার

Unix-এর সবচেয়ে পুরোনো সমাধান: প্রতিটি নতুন সংযোগের জন্য fork() দিয়ে একটি নতুন প্রসেস। fork() একবার ডাকলে দুবার ফেরে — parent-এ child-এর PID নিয়ে, আর নতুন child-এ 0 নিয়ে (বিস্তারিত অপারেটিং সিস্টেম কোর্সের process API পর্বে)। Child পায় parent-এর মেমরির একটি কপি আর — এই পর্বের জন্য সবচেয়ে জরুরি — parent-এর file descriptor টেবিলের কপি। তাই accept()-এর পরে fork করলে child-এর হাতেও সেই connected socket থাকে। কাঠামোটি এই:

for (;;) {
    int c = accept(ls, NULL, NULL);      /* parent waits for the next client */
    if (c < 0) continue;                 /* EINTR, ECONNABORTED ... try again */
    pid_t pid = fork();
    if (pid == 0) {                      /* ---- child ---- */
        close(ls);                       /* (1) child never accepts: drop the listening fd */
        serve(c);                        /* talk to this one client */
        close(c);
        _exit(0);
    }
    close(c);                            /* (2) parent never talks to the client: drop its copy */
}

দুটি close() কেন — socket-এর reference count

Kernel-এর ভেতরে একটি socket একটিই কাঠামো, কিন্তু তার দিকে একাধিক file descriptor নির্দেশ করতে পারে — fork-এর পরে parent-এর fd 4 আর child-এর fd 4 একই socket. Kernel গোনে কতগুলো fd এখনো এই socket খোলা রেখেছে — এটাই reference count. close() শুধু গণনা এক কমায়; গণনা শূন্য হলে তবেই socket সত্যিই বন্ধ হয়, আর TCP তখন অপর প্রান্তে FIN পাঠায় (পর্ব ২৯)। এ থেকে দুটি নিয়ম:

• Parent connected fd বন্ধ না করলে: child close(c) করলেও গণনা ১-এ আটকে থাকে, FIN যায় না; যে client “সংযোগ বন্ধ হলে বুঝব উত্তর শেষ” ধরে অপেক্ষা করে, সে ঝুলে থাকে। তার ওপর parent-এর fd প্রতি সংযোগে একটি করে জমে; fd সীমা (ulimit -n, প্রায়ই ১,০২৪) পেরোলে accept() EMFILE দিয়ে ব্যর্থ হয়।
• Child listening fd বন্ধ না করলে: প্রতিটি child listening socket ধরে রাখে; parent নতুন করে চালু হলে পুরোনো child-রা বেঁচে থাকা পর্যন্ত port “ব্যস্ত” থাকতে পারে, আর ভুল কোডে child নিজেও accept() করে ফেলতে পারে। নিয়ম: যে প্রসেস যে fd ব্যবহার করবে না, সে তা বন্ধ করবে।

নিচের stepper-এ একটি সংযোগের পুরো জীবন দেখুন — fd টেবিল, kernel-এর গণনা আর প্রসেসের অবস্থা ধাপে ধাপে।

Zombie ঠেকানো — SIGCHLD আর WNOHANG লুপ কেন

Parent প্রতিটি child-এর জন্য সাধারণ wait() ডাকলে child শেষ না হওয়া পর্যন্ত আটকে থাকত — আবার iterative সার্ভার! তাই parent SIGCHLD ধরে, আর handler-এ waitpid()-কে WNOHANG দিয়ে ডাকে — “শেষ হওয়া কেউ থাকলে দাও, না থাকলে সঙ্গে সঙ্গে ফেরো”. লুপ কেন? সাধারণ Unix signal জমা হয় না: তিনটি child প্রায় একসাথে শেষ হলে parent হয়তো একটিমাত্র SIGCHLD পায়, আর একবার waitpid() করলে বাকি দুজন zombie থেকে যেত। লুপ চলে ০ (আর কেউ শেষ হয়নি) বা −১ (কোনো child নেই, ECHILD) পাওয়া পর্যন্ত। বিস্তারিত OS কোর্সের process API পর্বের অংশ ৬–৭ আর signal পর্বে।

তিনটি জরুরি বিবরণ। এক, handler sigaction() দিয়ে SA_RESTART-সহ বসান — নাহলে accept()-এ আটকে থাকা parent EINTR পাবে, আর অসতর্ক কোড সেটাকে মারাত্মক ভুল ভেবে বন্ধ হয়ে যাবে। দুই, handler-এ waitpid() নিরাপদ, কিন্তু printf() বা malloc() নয় (async-signal-safe নয়); errno-ও সংরক্ষণ করে ফিরিয়ে দিন। তিন, POSIX সিস্টেমে SIGCHLD-এর action SIG_IGN করলে kernel নিজেই child তুলে নেয় — সহজ, কিন্তু তখন exit status জানা যায় না।

নিজে চালিয়ে দেখুন: iterative বনাম fork — সময় মেপে

নিচের প্রোগ্রাম loopback-এ (127.0.0.1, port OS বেছে দেয়) একটি সার্ভার প্রসেস চালায়, যার প্রতিটি request-এ ২০০ ms লাগে (usleep দিয়ে ধীর client-এর অনুকরণ)। তারপর একসাথে ৪টি client পাঠিয়ে মাপে সবাই উত্তর পেতে কত সময় লাগল — আগে iterative, তারপর SIGCHLD reaping-সহ fork সার্ভারে; শেষে সার্ভার যাচাই করে কোনো zombie বাকি আছে কি না।

#include <stdio.h>
#include <errno.h>
#include <signal.h>
#include <time.h>
#include <unistd.h>
#include <sys/wait.h>
#include <arpa/inet.h>
static volatile sig_atomic_t reaped;
static void on_chld(int s) { (void)s; int e = errno; while (waitpid(-1, NULL, WNOHANG) > 0) reaped++; errno = e; }
static void serve(int c) { char b; read(c, &b, 1); usleep(200000); write(c, &b, 1); close(c); } /* 200 ms */
static double now(void) { struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t); return t.tv_sec + t.tv_nsec / 1e9; }
int main(void) {
    for (int forking = 0; forking <= 1; forking++) {
        struct sockaddr_in a = {.sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK)}; socklen_t n = sizeof a;
        int ls = socket(AF_INET, SOCK_STREAM, 0); bind(ls, (struct sockaddr *)&a, n); listen(ls, 8);
        getsockname(ls, (struct sockaddr *)&a, &n); fflush(stdout); double t0 = now(); pid_t srv = fork();
        if (srv == 0) {                                          /* ===== server process ===== */
            struct sigaction sa = {.sa_handler = on_chld, .sa_flags = SA_RESTART}; sigaction(SIGCHLD, &sa, NULL);
            for (int i = 0; i < 4; i++) {
                int c = accept(ls, NULL, NULL);
                if (!forking) { serve(c); continue; }            /* iterative: one client at a time */
                if (fork() == 0) { close(ls); serve(c); _exit(0); } /* child: only this client */
                close(c); }                                      /* parent: drop its copy, accept again */
            while (forking && reaped < 4) usleep(1000);
            printf("  server: reaped=%d, zombies left: %s\n", (int)reaped,
                   waitpid(-1, NULL, WNOHANG) < 0 && errno == ECHILD ? "none (ECHILD)" : "YES");
            fflush(stdout); _exit(0); }
        close(ls); for (int i = 0; i < 4; i++) if (fork() == 0) {  /* ===== 4 clients at once ===== */
            int s = socket(AF_INET, SOCK_STREAM, 0); char b = 'x';
            connect(s, (struct sockaddr *)&a, sizeof a); write(s, &b, 1); read(s, &b, 1); _exit(0); }
        for (int left = 4, p; left > 0; ) if ((p = wait(NULL)) != srv) left--; else srv = 0;
        double t = now() - t0; if (srv) waitpid(srv, NULL, 0);
        printf("%-14s 4 clients x 200 ms -> all done in %.1f s\n", forking ? "fork-per-conn:" : "iterative:", t);
    }
}

  server: reaped=0, zombies left: none (ECHILD)
iterative:     4 clients x 200 ms -> all done in 0.8 s
  server: reaped=4, zombies left: none (ECHILD)
fork-per-conn: 4 clients x 200 ms -> all done in 0.2 s

৩ · fork-এর খরচ আর ইতিহাস — copy-on-write, inetd আর prefork

“প্রতি সংযোগে একটি পুরো প্রসেস কপি” — ১০০ MB-র সার্ভার হলে প্রতি client-এ আরও ১০০ MB? আধুনিক OS তা করে না। Copy-on-write (COW)-এ fork-এর সময় পাতা কপি হয় না; parent আর child একই পাতা শেয়ার করে, আর কেউ কোনো পাতায় লিখলে তবেই সেই পাতাটি কপি হয় (OS কোর্সের virtual memory পর্বের অংশ ৫)। তবু fork বিনামূল্যে নয়:

• Page table কপি: পাতার মানচিত্র কপি করতে হয়; অনেক GB মেমরির প্রসেসে fork মিলিসেকেন্ড পর্যন্ত নিতে পারে।
• পরে লেখার খরচ: child যত পাতায় লেখে, তত পাতা কপি হয় — page fault আর মেমরি দুটোই বাড়ে।
• Context switch: প্রতিটি প্রসেসের আলাদা address space, তাই প্রসেস বদলাতে TLB-র মতো cache-এর উষ্ণতা হারায় (OS কোর্সের context switch পর্বের অংশ ৫)।
• ভাগাভাগি কঠিন: মেমরি আলাদা, তাই “কতজন সংযুক্ত” জাতীয় একটি counter শেয়ার করতেও IPC লাগে।

বিনিময়ে fork দেয় সবচেয়ে বড় উপহার — বিচ্ছিন্নতা (isolation). একটি child-এ segmentation fault হলে শুধু সেই client-এর সংযোগ যায়, বাকিরা নিরাপদ; প্রতিটি child আলাদা ব্যবহারকারীর অধিকারেও চলতে পারে। এজন্য আজও PostgreSQL প্রতিটি client সংযোগে একটি আলাদা backend প্রসেস চালায়, আর OpenSSH-এর sshd প্রতিটি সংযোগে নতুন প্রসেস তৈরি করে।

৪ · প্রতি সংযোগে একটি থ্রেড — pthreads আর &connfd-এর ফাঁদ

একটি প্রসেসের ভেতরে একাধিক থ্রেড চলতে পারে — সবাই একই মেমরি, একই fd টেবিল, একই global variable শেয়ার করে, শুধু প্রত্যেকের নিজের stack আর register (OS কোর্সের থ্রেড পর্ব)। নতুন থ্রেড তৈরি fork-এর চেয়ে সস্তা: address space কপি নেই, page table কপি নেই। POSIX threads (pthreads) দিয়ে thread-per-connection সার্ভারের কাঠামো fork সার্ভারের মতোই, শুধু fork()-এর জায়গায় pthread_create():

static void *serve_thread(void *arg) {
    int c = *(int *)arg;  free(arg);      /* take my own copy, then free it */
    pthread_detach(pthread_self());       /* nobody will join me: free my resources at exit */
    serve(c);
    close(c);                             /* threads share ONE fd table: exactly one close */
    return NULL;
}
for (;;) {
    int *p = malloc(sizeof *p);
    *p = accept(ls, NULL, NULL);          /* each connection gets its own heap int */
    pthread_t t;
    if (*p < 0 || pthread_create(&t, NULL, serve_thread, p) != 0) { if (*p >= 0) close(*p); free(p); }
}

fork সার্ভারের সাথে দুটি পার্থক্য। প্রথমত, main connected fd বন্ধ করে না — থ্রেডেরা একটিই fd টেবিল শেয়ার করে; fork-এর অভ্যাসে main close(c) করলে থ্রেডের হাত থেকে socket কেড়ে নেওয়া হতো! দ্বিতীয়ত, pthread_detach(): শেষ হওয়া থ্রেডের কিছু অবশিষ্ট থাকে যতক্ষণ না কেউ pthread_join() করে — অনেকটা zombie-র মতো। এখানে কেউ join করবে না, তাই detach, যাতে শেষ হলেই সম্পদ ফেরত যায় (pthreads পর্বের অংশ ৩)।

ক্লাসিক বাগ: &connfd পাঠানো

অনেক টিউটোরিয়াল আর AI-এর কোডে দেখা যায়: connfd = accept(…); pthread_create(&t, NULL, serve, &connfd);. থ্রেডকে দেওয়া হলো main-এর একটি variable-এর ঠিকানা, মান নয়। pthread_create() ফেরার আগে নতুন থ্রেড চলা শুরু করবে, এমন নিশ্চয়তা নেই; এর মধ্যে আরেকটি client এলে main connfd-এ নতুন মান লেখে, আর প্রথম থ্রেড পরে *arg পড়ে পায় দ্বিতীয় client-এর fd. এটি একটি data race — এক থ্রেড লিখছে, অন্যটি পড়ছে, মাঝে কোনো সমন্বয় নেই।

1int connfd;                  // ONE variable in main2for (;;) {3  connfd = accept(ls, 0, 0);4  pthread_create(&t, 0, serve, &connfd); // BUG5}6void *serve(void *arg) {7  int fd = *(int *)arg;      // read LATER8  talk(fd); close(fd); }9// FIX: p = malloc; *p = connfd; pass p

নিজে চালিয়ে দেখুন: race নিরাপদে, প্রতিবার একই ফল

আসল race মাঝে মাঝে ঘটে, তাই পরীক্ষায় লুকিয়ে থাকে। নিচের প্রোগ্রাম ইচ্ছা করে “সবচেয়ে খারাপ scheduling” তৈরি করে: থ্রেডগুলো একটি pthread_barrier-এ অপেক্ষা করে, যতক্ষণ না main তিনটি সংযোগই accept() করে — stepper-এর ধাপ ২–৪, কিন্তু প্রতিবার নিশ্চিতভাবে। তারপর একই কাজ malloc করা কপি দিয়ে, সব loopback-এ।

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <arpa/inet.h>
static pthread_barrier_t gate;  /* threads wait here until main has accepted all 3 (= worst-case scheduling) */
static int heap;                /* 0 = pass &connfd (bug), 1 = pass a malloc'ed copy (fix) */
static void *serve(void *arg) {
    pthread_barrier_wait(&gate);
    int fd = *(int *)arg;       /* "which connection is mine?" -- read only now */
    if (heap) free(arg);        /* the thread owns its copy */
    return (void *)(intptr_t)fd;
}
int main(void) {
    struct sockaddr_in a = {.sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK)};
    socklen_t n = sizeof a; int ls = socket(AF_INET, SOCK_STREAM, 0), cl[3], acc[3], connfd;
    bind(ls, (struct sockaddr *)&a, n); listen(ls, 8); getsockname(ls, (struct sockaddr *)&a, &n);
    for (heap = 0; heap <= 1; heap++) {
        pthread_t t[3]; pthread_barrier_init(&gate, NULL, 4);
        printf(heap ? "FIX: arg = malloc'ed copy of connfd\n" : "BUG: arg = &connfd\n");
        for (int i = 0; i < 3; i++) {
            cl[i] = socket(AF_INET, SOCK_STREAM, 0); connect(cl[i], (struct sockaddr *)&a, sizeof a);
            acc[i] = connfd = accept(ls, NULL, NULL);
            int *p = &connfd;                                    /* the classic bug */
            if (heap) { p = malloc(sizeof *p); *p = connfd; }    /* the fix */
            pthread_create(&t[i], NULL, serve, p);
            printf("  main: accepted fd %d -> thread %d\n", connfd, i); }
        pthread_barrier_wait(&gate);                             /* now let the threads run */
        for (int i = 0; i < 3; i++) {
            void *r; pthread_join(t[i], &r); int fd = (int)(intptr_t)r;
            printf("  thread %d serves fd %d%s\n", i, fd, fd == acc[i] ? "" : "   <-- WRONG"); close(cl[i]); close(acc[i]); }
        pthread_barrier_destroy(&gate);
    }
}

BUG: arg = &connfd
  main: accepted fd 5 -> thread 0
  main: accepted fd 7 -> thread 1
  main: accepted fd 9 -> thread 2
  thread 0 serves fd 9   <-- WRONG
  thread 1 serves fd 9   <-- WRONG
  thread 2 serves fd 9
FIX: arg = malloc'ed copy of connfd
  main: accepted fd 5 -> thread 0
  main: accepted fd 7 -> thread 1
  main: accepted fd 9 -> thread 2
  thread 0 serves fd 5
  thread 1 serves fd 7
  thread 2 serves fd 9

প্রতি থ্রেডে কত মেমরি — আর থ্রেডের সীমা

প্রতিটি থ্রেডের নিজের stack লাগে। Linux-এ glibc সাধারণত এর আকার নেয় প্রসেসের stack সীমা থেকে (ulimit -s, অনেক distro-তে 8192 KB = ৮ MiB), যদি না প্রোগ্রাম pthread_attr_setstacksize() দিয়ে অন্য মান দেয়। তবে এটি virtual সংরক্ষণ — আসল RAM লাগে শুধু ছোঁয়া পাতার জন্য, একটি সাধারণ সংযোগ-থ্রেডে প্রায়ই কয়েক থেকে কয়েক দশ KB. অন্য OS-এ ডিফল্ট আলাদা (Windows-এ সাধারণত ১ MB, macOS-এ মূল থ্রেড ছাড়া অন্যগুলোতে সাধারণত ৫১২ KB) — নিজের সিস্টেমে মেপে নিন।

হিসাব: ১০,০০০ থ্রেড × ৮ MiB = ৮০,০০০ MiB ≈ ৭৮ GiB virtual address space. ৬৪-bit-এ সমস্যা নেই, কিন্তু ৩২-bit সিস্টেমে (user space মোটামুটি ৩ GiB) ৪০০-র কম থ্রেডেই জায়গা শেষ হতো — এক সময়ের বাস্তব দেয়াল। আজকের সীমা অন্যখানে: /proc/sys/kernel/threads-max, ulimit -u, container-এর pids সীমা, আর হাজার হাজার জেগে ওঠা থ্রেডের context switch. তাই thread-per-connection শত বা কয়েক হাজার সংযোগে ভালো, অগণিত সংযোগে নয়।

৫ · ভাগাভাগির অবস্থা — counter-এ race, mutex আর atomic

থ্রেডের সুবিধা — সবাই একই মেমরি দেখে — একই সাথে তার বিপদ। ধরুন সার্ভার রাখে “এখন কতজন সংযুক্ত” (active), যাতে সীমা পেরোলে নতুনদের ফেরানো যায়; প্রতিটি থ্রেড শুরুতে active++ আর শেষে active-- করে। C-তে এক লাইন, কিন্তু CPU-তে তিন ধাপ: মেমরি থেকে পড়া (load), এক যোগ করা (add), মেমরিতে লেখা (store). দুই থ্রেড প্রায় একসাথে করলে:

   T1                     T2                    active (মেমরিতে)
   load  41                                      41
                          load  41               41
   add → 42                                      41
                          add → 42               41
   store 42                                      42
                          store 42               42   ← দুটি সংযোগ, অথচ বাড়ল মাত্র ১

একটি বৃদ্ধি হারিয়ে গেল (lost update). active-- হারালে counter ধীরে ধীরে বাড়তেই থাকে, আর একদিন “সীমা পূর্ণ” ভেবে সার্ভার সবাইকে ফিরিয়ে দেয়, যদিও আসলে কেউ নেই। এমন data race কম লোডে প্রায় ঘটেই না, ধরা পড়ে ভিড়ের দিনে। সমাধান তিনটি:

long active;                                   /* (1) RACE: active++ = load, add, store */
void on_open_racy(void)   { active++; }

pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; /* (2) MUTEX: one thread at a time */
void on_open_mutex(void)  { pthread_mutex_lock(&m); active++; pthread_mutex_unlock(&m); }

#include <stdatomic.h>                         /* (3) ATOMIC (C11): one indivisible step */
atomic_long active_a;
void on_open_atomic(void) { atomic_fetch_add(&active_a, 1); }

mutex দিয়ে ঘেরা অংশটুকুকে বলে critical section — সেখানে যত কম কাজ, তত ভালো। একটি সাধারণ ভুল: mutex ধরে রেখে নেটওয়ার্কে write() করা — ধীর client-এর জন্য সব থ্রেড লাইনে দাঁড়ায়, আর concurrent সার্ভার আবার iterative হয়ে যায়। তত্ত্ব আর ভেতরের কৌশল OS কোর্সের mutex আর semaphore, atomic আর spinlock আর race condition পর্বে।

৬ · Thread pool — bounded queue, backpressure আর pool-এর আকার

Thread-per-connection-এর দুটি দুর্বলতা: প্রতি সংযোগে থ্রেড তৈরি আর ধ্বংসের খরচ, আর সবচেয়ে বড় কথা — কোনো সীমা নেই. হঠাৎ ২০,০০০ client এলে সার্ভার ২০,০০০ থ্রেড তৈরির চেষ্টা করবে, আর মেমরি ও scheduler ভেঙে পড়বে। Thread pool দুটোরই সমাধান: শুরুতেই নির্দিষ্ট সংখ্যক (W) worker থ্রেড, যারা কখনো শেষ হয় না; আর মাঝখানে একটি bounded queue — নির্দিষ্ট ধারণক্ষমতার সারি।

এটি OS-এর ক্লাসিক producer-consumer সমস্যা (ক্লাসিক সমস্যা পর্বের অংশ ২): producer = accept loop, যে connected fd queue-তে রাখে; consumer = worker, যারা fd তুলে client-কে সেবা দেয়। লাগে একটি mutex আর দুটি condition variable: not_empty (queue খালি হলে worker এখানে ঘুমায়) আর not_full (queue ভরা হলে producer এখানে ঘুমায়)। অপেক্ষা সবসময় while লুপে — জেগে উঠে শর্ত আবার যাচাই করতে হয় (condition variable পর্বের অংশ ৩)।

নিজে চালিয়ে দেখুন: ৩ worker, queue ৪, ৮টি কাজ

নিচের প্রোগ্রামে producer ৮টি কাজ (বাস্তবে ৮টি connected fd) এক ঝটকায় queue-তে দিতে চায়; queue-তে জায়গা ৪টি, worker ৩টি, প্রতিটি কাজে ৫০ ms. প্রতিটি worker একটি mutex-রক্ষিত counter বাড়ায় আর লিখে রাখে কোন কাজ কে করল; শেষে main সারাংশ ছাপে।

#include <stdio.h>
#include <stdint.h>
#include <pthread.h>
#include <unistd.h>
#define CAP 4                 /* bounded queue capacity */
#define NJOBS 8               /* 8 connections arrive in a burst */
static int q[CAP], head, count, maxq, stop, served, by[NJOBS + 1];
static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER, not_full = PTHREAD_COND_INITIALIZER;
static void put(int job) {                                   /* producer = the accept() loop */
    pthread_mutex_lock(&m);
    while (count == CAP) pthread_cond_wait(&not_full, &m);   /* full: wait = backpressure */
    q[(head + count++) % CAP] = job; if (count > maxq) maxq = count;
    pthread_cond_signal(&not_empty); pthread_mutex_unlock(&m);
}
static void *worker(void *arg) {                             /* consumer */
    for (int id = (int)(intptr_t)arg;;) {
        pthread_mutex_lock(&m);
        while (count == 0 && !stop) pthread_cond_wait(&not_empty, &m);
        if (count == 0) { pthread_mutex_unlock(&m); return NULL; }   /* stopping and drained */
        int job = q[head]; head = (head + 1) % CAP; count--;
        pthread_cond_signal(&not_full); pthread_mutex_unlock(&m);
        usleep(50000);                                       /* serve one slow client: 50 ms */
        pthread_mutex_lock(&m); served++; by[job] = id; pthread_mutex_unlock(&m);
    }
}
int main(void) {
    pthread_t w[3];
    for (intptr_t i = 0; i < 3; i++) pthread_create(&w[i], NULL, worker, (void *)(i + 1));
    for (int j = 1; j <= NJOBS; j++) put(j);
    pthread_mutex_lock(&m); stop = 1; pthread_cond_broadcast(&not_empty); pthread_mutex_unlock(&m);
    for (int i = 0; i < 3; i++) pthread_join(w[i], NULL);    /* graceful shutdown: finish, then join */
    printf("job:worker "); for (int j = 1; j <= NJOBS; j++) printf(" %d:W%d", j, by[j]);
    printf("\nserved=%d (expected %d), longest queue=%d (capacity %d)\n", served, NJOBS, maxq, CAP);
}

job:worker  1:W1 2:W2 3:W3 4:W3 5:W2 6:W1 7:W2 8:W1
served=8 (expected 8), longest queue=4 (capacity 4)

Queue ভরা হলে — অপেক্ষা না প্রত্যাখ্যান?

Backpressure (producer থামে) সহজ, কাউকে সরাসরি “না” বলে না, কিন্তু চাপ ঠেলে দেয় kernel-এর accept queue-তে, যেখানে client অন্ধকারে অপেক্ষা করে হয়তো timeout হয়ে যান। দ্রুত প্রত্যাখ্যান (load shedding) সঙ্গে সঙ্গে জানায় “এখন ব্যস্ত” — client বা load balancer অন্য সার্ভারে যেতে পারে, আর ভেতরের সবার latency ঠিক থাকে। যে নীতিই নিন, সীমাহীন queue কখনো নয়: চাপের সময় সে শুধু মেমরি খায় আর latency বাড়ায় — পেছনের অনুরোধ যখন সেবা পায়, client ততক্ষণে চলে গেছেন।

Pool কত বড় হবে — দুটি নিয়ম আর Little-এর সূত্র

কোনো সূত্রই নিখুঁত নয়; শুরুর অনুমান নিয়ে মেপে ঠিক করতে হয়। দুটি প্রচলিত হাতের নিয়ম:

• CPU-bound কাজ (হিসাব, compression): worker ≈ core-এর সংখ্যা (কখনো core + ১)। বেশি থ্রেড শুধু context switch বাড়ায়।
• I/O-bound কাজ (ডেটাবেস বা ধীর client-এর অপেক্ষা): worker ≈ core × (১ + অপেক্ষার সময় / CPU-র সময়) — Brian Goetz-দের Java Concurrency in Practice বইয়ের মাধ্যমে পরিচিত রূপ। উদাহরণ: ৮ core, প্রতিটি request-এ ১০ ms CPU আর ৯০ ms অপেক্ষা → ৮ × (১ + ৯০/১০) = ৮০টি worker; তবু CPU-র সর্বোচ্চ সামর্থ্য ৮ ÷ ১০ ms = সেকেন্ডে ৮০০ request.

আরেকটি শক্ত হাতিয়ার Little-এর সূত্র (পর্ব ০৫-এর queue মনে করুন): দীর্ঘ সময়ের গড়ে L = λ × W — একসাথে থাকা request-এর গড় সংখ্যা = আগমনের হার × প্রতিটির গড় সময়। প্রতিটি request পুরো সময় একটি থ্রেড ধরে রাখলে worker লাগবে কমপক্ষে L. উদাহরণ: সেকেন্ডে ৫০০ request, প্রতিটিতে ২০০ ms → L = ৫০০ × ০.২ = ১০০; এর কম worker হলে queue অবিরাম বাড়বে। Queue-র আকার ঠিক হয় সহ্যযোগ্য অপেক্ষা দিয়ে — কাউকে ২ সেকেন্ডের বেশি বসানো চলবে না আর সার্ভার সেকেন্ডে ৫০০ সামলায়, তাহলে queue ≤ ১,০০০.

৭ · Pre-fork, pre-thread আর thundering herd

Thread pool-এ একজন producer accept() করে কাজ হাতবদল করে। আরও সরল একটি পুরোনো নকশা: সবাই নিজে accept() করে. সার্ভার শুরুতেই listening socket খুলে কয়েকটি প্রসেস fork করে (pre-forked) বা কয়েকটি থ্রেড তৈরি করে (pre-threaded), আর প্রত্যেকে একই listening fd-তে accept() ডেকে বসে থাকে; kernel-এর accept queue-ই সারি। Apache-র prefork MPM এমনই: অলস child-এর সংখ্যা একটি সীমার মধ্যে রাখা, আর মেমরি-লিক থেকে বাঁচতে নির্দিষ্ট সংখ্যক সংযোগের পরে child নতুন করে তৈরি (MaxConnectionsPerChild).

Thundering herd — একটি সংযোগের জন্য সবাই জাগে

একশটি প্রসেস একই socket-এর অপেক্ষায়, একটি সংযোগ এল — kernel সবাইকে জাগালে একজনই সংযোগ পায়, বাকি নিরানব্বই জন জেগে, CPU নিয়ে, আবার ঘুমায়। একে বলে thundering herd. পুরোনো Unix আর প্রথম দিকের Linux-এ blocking accept()-এ এই সমস্যা ছিল বলে প্রচলিত ইতিহাসে বলা হয়; Linux বহু বছর ধরে সেখানে সাধারণত একজনকেই জাগায়। কিন্তু প্রতিটি worker নিজের epoll দিয়ে listening socket পাহারা দিলে (পর্ব ৪৪) সমস্যা ফিরে আসে; এজন্য Linux-এ পরে EPOLLEXCLUSIVE যোগ হয় (kernel ৪.৫-এর দিকে), আর কিছু পুরোনো সার্ভার accept-এর আগে নিজেদের মধ্যে একটি lock নিত (Apache-র “accept mutex”).

SO_REUSEPORT — প্রত্যেকের নিজের listening socket

আধুনিক আরেকটি সমাধান SO_REUSEPORT (Linux-এ kernel ৩.৯ থেকে, ২০১৩ সালের দিকে; BSD-তে আচরণ কিছুটা আলাদা)। প্রতিটি worker নিজের listening socket খোলে, সবাই একই port-এ bind করে, আর kernel নতুন সংযোগ 4-tuple-এর hash দিয়ে কোনো একটির queue-তে দেয় — ভাগের queue নিয়ে টানাটানি নেই, বহু-core মেশিনে ভার ভালো ছড়ায় (nginx-এর listen … reuseport). মূল্য: একটি worker ব্যস্ত থাকলেও তার queue-তে নতুন সংযোগ আসতে থাকে, পাশের worker অলস থাকলেও; আর একটি listening socket বন্ধ হলে তার queue-র সংযোগ হারাতে পারে। (SO_REUSEADDR ভিন্ন জিনিস — TIME_WAIT থাকা অবস্থায় আবার bind করতে দেয়।)

৮ · পাঁচ মডেলের তুলনা আর বাস্তবের সার্ভার

নিজে চালিয়ে দেখুন: হঠাৎ ভিড়ে কোন মডেল কেমন

সরল মডেল: t = 0-তে N জন ধীর client একসাথে এল; প্রতিটি request-এ ২০০ ms, প্রায় পুরোটা অপেক্ষা। একসাথে k-টি চলে, আরও Q-টি queue-তে বসে, বাকিরা সঙ্গে সঙ্গে প্রত্যাখ্যাত; ১ সেকেন্ডের বেশি অপেক্ষা করলে client হাল ছাড়েন (“late”). প্রতি থ্রেডে ২ MB আর মোট ৬৪ MB বাজেট — অনুমান, নিজের সার্ভারে মেপে বদলে নিন।

// A burst of N slow clients arrives at t = 0. Each request needs S ms, mostly WAITING (slow client, disk),
// so CPU is not the bottleneck. k requests run in parallel, Q more wait in a queue, the rest are refused.
// A client gives up after TIMEOUT ms. THREAD_MB and MEM_MB are assumptions -- measure your own server.
const S = 200, TIMEOUT = 1000, THREAD_MB = 2, MEM_MB = 64;
function run(name, N, k, Q) {
  let ok = 0, late = 0, refused = 0, sum = 0, worst = 0;
  for (let i = 0; i < N; i++) {
    if (i >= k + Q) { refused++; continue; }         // no worker, no queue slot: refuse fast (e.g. 503)
    const t = (Math.floor(i / k) + 1) * S;            // waits floor(i/k) rounds, then is served
    sum += t; worst = Math.max(worst, t);
    if (t <= TIMEOUT) ok++; else late++;              // late = client already gave up
  }
  const mem = Math.min(N, k) * THREAD_MB;
  const avg = ok + late ? Math.round(sum / (ok + late)) : 0;
  console.log(name.padEnd(24) + [N, ok, late, refused, avg, worst].map(v => String(v).padStart(8)).join("") +
    (mem + " MB" + (mem > MEM_MB ? " (!)" : "")).padStart(12));
}
console.log("model".padEnd(24) + ["N", "ok", "late", "refused", "avg ms", "worst"].map(h => h.padStart(8)).join("") +
  "memory".padStart(12));
for (const N of [20, 200]) {
  run("iterative", N, 1, Infinity);
  run("thread/conn, no cap", N, N, 0);
  run("thread/conn, cap " + MEM_MB / THREAD_MB, N, Math.min(N, MEM_MB / THREAD_MB), 0);
  run("pool 16 + queue 48", N, 16, 48);
}
console.log(`(!) = more than the ${MEM_MB} MB memory budget; ok = answered within ${TIMEOUT} ms`);

model                          N      ok    late refused  avg ms   worst      memory
iterative                     20       5      15       0    2100    4000        2 MB
thread/conn, no cap           20      20       0       0     200     200       40 MB
thread/conn, cap 32           20      20       0       0     200     200       40 MB
pool 16 + queue 48            20      20       0       0     240     400       32 MB
iterative                    200       5     195       0   20100   40000        2 MB
thread/conn, no cap          200     200       0       0     200     200  400 MB (!)
thread/conn, cap 32          200      32       0     168     200     200       64 MB
pool 16 + queue 48           200      64       0     136     500     800       32 MB
(!) = more than the 64 MB memory budget; ok = answered within 1000 ms

বাস্তবের সার্ভার কী করে

• Apache httpd: concurrency মডেল একটি বদলযোগ্য অংশ — MPM. prefork = প্রতি সংযোগে একটি প্রসেস; worker = কয়েকটি প্রসেস, প্রত্যেকে অনেক থ্রেড; event = worker-এর মতো, কিন্তু অলস keep-alive সংযোগ একটি আলাদা listener থ্রেড পাহারা দেয়। আধুনিক distro-তে সাধারণত event-ই ডিফল্ট।
• nginx: শুরু থেকেই event-driven — একটি master আর সাধারণত core-প্রতি একটি worker প্রসেস, প্রত্যেকে epoll দিয়ে হাজার হাজার সংযোগ চালায়; একটি worker মরলে master নতুন worker চালায়।
• Node.js: JavaScript চলে এক থ্রেডের event loop-এ (libuv); ফাইল সিস্টেম বা DNS-এর মতো blocking কাজ যায় libuv-এর ছোট thread pool-এ (ডিফল্ট ৪টি থ্রেড)।
• Go: প্রতিটি সংযোগে একটি goroutine, সরলরেখার blocking কোড — কিন্তু goroutine হালকা (stack শুরু কয়েক KB-তে), আর runtime এগুলোকে অল্প কয়েকটি OS থ্রেডে চালায়, ভেতরে epoll-এর মতো netpoller দিয়ে। Java ২১-এর virtual thread একই পথে।
• ডেটাবেস: PostgreSQL প্রতি সংযোগে প্রসেস, MySQL ডিফল্টে প্রতি সংযোগে থ্রেড — তাই সামনে প্রায়ই connection pool রাখা হয়।

কখন কোনটা? শেখা বা খুব কম ব্যবহারকারী — iterative. ঝুঁকিপূর্ণ বা আলাদা অধিকারের কাজ (লগইন) — fork. মাঝারি সংখ্যক ব্যস্ত সংযোগ আর সরল কোড — thread pool. অগণিত, বেশিরভাগ অলস সংযোগ (chat, WebSocket, IoT) — event-driven (পর্ব ৪৪) বা হালকা থ্রেড। বড় সার্ভার প্রায়ই মিশ্রণ: event loop সংযোগ পাহারা দেয়, blocking কাজ যায় thread pool-এ। পর্ব ৪৫-এর HTTP সার্ভার প্রজেক্টে এর একটি ছোট রূপ নিজে বানাবেন।

৯ · Timeout, ধীর client আর graceful shutdown

প্রতিটি client-এর timeout

থ্রেড আর প্রসেস মডেলে প্রতিটি সংযোগ একটি worker দখল করে রাখে। কেউ সংযোগ খুলে চুপ করে থাকলে read() চিরকাল অপেক্ষা করবে; ১৬ জন এমন client = ১৬ worker-এর pool অচল, অথচ CPU অলস। তাই প্রতিটি সংযোগে timeout বাধ্যতামূলক:

struct timeval tv = { .tv_sec = 10, .tv_usec = 0 };            /* 10 s of silence is enough */
setsockopt(c, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);        /* read() fails with EAGAIN */
setsockopt(c, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof tv);        /* write() too, if client never reads */
ssize_t n = read(c, buf, sizeof buf);
if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) { close(c); /* give the worker back */ }

কিন্তু শুধু নীরবতার timeout যথেষ্ট নয়। Slowloris নামে পরিচিত আক্রমণ-ধারণায় (২০০৯ সালের দিকে ব্যাপক আলোচিত) একজন client অনেক সংযোগ খুলে প্রতিটিতে প্রতি কয়েক সেকেন্ডে header-এর কয়েকটি বাইট পাঠান, কখনো শেষ করেন না। প্রতিটি read() সময়মতো কিছু পায়, তাই idle timeout বাজে না, অথচ প্রতিটি সংযোগ একটি worker আটকে রাখে — অল্প bandwidth-এই একটি denial-of-service. প্রতিরক্ষা (নিজের সার্ভারে):

• মোট সময়সীমা (deadline): “পুরো header ২০ সেকেন্ডের মধ্যে” ধরনের সীমা আর ন্যূনতম গতি (Apache-র mod_reqtimeout, nginx-এর client_header_timeout).
• প্রতি IP-তে সংযোগের সীমা (nginx-এর limit_conn) — তবে NAT-এর পেছনে বহু ব্যবহারকারী একই IP শেয়ার করেন (পর্ব ১৯), তাই খুব কম নয়।
• সামনে event-driven reverse proxy: nginx-এ অলস সংযোগের খরচ কয়েক KB; সে ধীর client সামলে শুধু সম্পূর্ণ request পেছনের অ্যাপে পাঠায় — সবচেয়ে প্রচলিত সমাধান।
• দ্রুত প্রত্যাখ্যান: অংশ ৬-এর bounded queue. বড় আকারের আক্রমণ ও প্রতিরক্ষা পর্ব ৫০-এ।

Graceful shutdown — কাউকে মাঝপথে না ফেলে বন্ধ করা

হঠাৎ মেরে ফেললে (SIGKILL) চলমান সব request মাঝপথে কেটে যায় — কারও টাকা পাঠানোর মাঝখানে! Graceful shutdown-এর ধাপ:

1. সংকেত: সাধারণত SIGTERM (systemd, docker stop, Kubernetes প্রথমে এটিই পাঠায়)। Handler শুধু একটি volatile sig_atomic_t পতাকা বসায় (signal পর্বের অংশ ৬ আর ৮)।
2. নতুন সংযোগ বন্ধ: accept loop থামে, listening socket বন্ধ হয়; load balancer থাকলে আগে তাকে জানানো ভালো।
3. চলমান কাজ শেষ: pool-এ stop = 1 আর broadcast (অংশ ৬-এর প্রোগ্রামের মতো); fork মডেলে parent child-দের অপেক্ষা করে।
4. সময়সীমা: কেউ আটকে থাকলে নির্দিষ্ট সময় পরে জোর করে বন্ধ — Kubernetes-ও grace period (ডিফল্ট সাধারণত ৩০ সেকেন্ড) পরে SIGKILL পাঠায়।
5. Join আর বের হওয়া: সব worker join, লগ flush, তারপর exit. nginx-এ nginx -s quit এই graceful পথ, nginx -s stop দ্রুত পথ।

১০ · AI-এর যুগে concurrent সার্ভার

“C-তে একটি multi-threaded TCP সার্ভার লিখে দাও” — AI কয়েক সেকেন্ডে কোড দেয়, আর সেটি প্রথম পরীক্ষায় ঠিকঠাক চলে। কিন্তু এই বিষয়ের বাগ দেখা দেয় ভিড়ের দিনে। AI-এর সার্ভার-কোডে বারবার দেখা যায় এমন ভুল:

AI-এর সার্ভার-কোড মানার আগে — চেকলিস্ট

• প্রতিটি fd কে খোলে, কে বন্ধ করে, ঠিক একবার — fork মডেলে parent আর child দুদিকেই মিলিয়েছি
• থ্রেডকে দেওয়া argument প্রতি সংযোগে আলাদা মেমরিতে, আর কে free করে তা স্পষ্ট
• প্রতিটি ভাগের variable-এর জন্য একটি lock বা atomic আছে; gcc -fsanitize=thread দিয়ে চালিয়ে কোনো সতর্কবার্তা পাইনি
• Queue সীমিত, timeout আছে, আর নিজের loopback-এ শত শত সংযোগ দিয়ে লোড টেস্ট করে fd আর zombie গুনেছি (/proc/PID/fd, ps)
• Default মান আর API-র আচরণ man page-এ মিলিয়েছি (man 2 accept, man 7 socket, man 3 pthread_create); লোড টেস্ট শুধু নিজের বা অনুমতিপ্রাপ্ত সার্ভারে করেছি