fork و exec و wait

1. fork: انسخ نفسك

الحاجة الغريبة إن fork() بترجع مرتين: مرة في الـ Parent ومرة في الـ Child، بقيمتين مختلفتين، وده اللي بيخلّي كل واحد يعرف هو مين:

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

int main(void) {
    int jobs = 3;
    printf("before fork: pid=%d\n", getpid());

    pid_t pid = fork();                  // من هنا فيه Processين

    if (pid < 0) {
        perror("fork");                  // فشلت (مثلاً وصلت لحد عدد الـ Processes)
        return 1;
    } else if (pid == 0) {
        jobs += 10;                      // ده بيغيّر نسخة الـ Child بس
        printf("child:  pid=%d parent=%d jobs=%d\n", getpid(), getppid(), jobs);
    } else {
        waitpid(pid, NULL, 0);           // استنى الـ Child يخلص
        printf("parent: pid=%d child=%d jobs=%d\n", getpid(), pid, jobs);
    }
    return 0;
}

$ gcc spawn.c -o spawn && ./spawn
before fork: pid=5001
child:  pid=5002 parent=5001 jobs=13
parent: pid=5001 child=5002 jobs=3

ومن غير waitpid، مين يطبع الأول؟ مش معروف. الاتنين Processes مستقلين، والـ Scheduler هو اللي يقرر. ده Non-determinism، وهو نفس أصل مشاكل الـ Concurrency.

fork بتعمل نسخة من الـ Process، وبترجع 0 في النسخة والـ PID في الأصل. والاتنين بيكمّلوا من نفس السطر، كل واحد بذاكرة منفصلة.

2. exec: بدّل البرنامج

الـ fork بتعمل نسخة من نفس البرنامج. طب لو عايز تشغّل برنامج تاني خالص؟

pid_t pid = fork();
if (pid == 0) {
    char *argv[] = { "ls", "-la", "/var/www", NULL };
    execvp("ls", argv);                  // الـ Child بقى ls
    perror("execvp");                    // السطر ده بيتنفذ بس لو exec فشلت
    _exit(127);
}
int status;
waitpid(pid, &status, 0);
printf("ls exited with %d\n", WEXITSTATUS(status));

3. ليه مش System Call واحد “شغّل البرنامج ده”؟

Windows عنده CreateProcess بيعمل كل حاجة مرة واحدة. ليه UNIX قسّمها لاتنين؟ لأن الفترة بين fork و exec هي فرصة الـ Child يجهّز البيئة للبرنامج الجديد، والبرنامج الجديد مايعرفش أي حاجة عن ده. ومن هنا جت الـ Redirection والـ Pipes:

pid_t pid = fork();
if (pid == 0) {
    close(STDOUT_FILENO);                                     // اقفل fd 1 (الشاشة)
    open("files.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);    // أصغر fd فاضي = 1، فالملف بقى هو الـ stdout
    execlp("ls", "ls", NULL);                                 // ls بيكتب على fd 1 زي العادة… وده بقى الملف
}
waitpid(pid, NULL, 0);

ls نفسه مايعرفش إنه بيكتب في ملف. هو بيكتب على fd 1 زي ما بيعمل دايماً. والـ Pipe (ls | grep php) نفس الفكرة: الـ Shell بيعمل pipe()، وبيعمل fork مرتين، ويوصّل الـ stdout بتاع الأول بالـ stdin بتاع التاني قبل الـ exec.

الفصل بين fork و exec بيدّي فرصة تغيّر بيئة البرنامج الجديد (ملفاته، وفولدره، وصلاحياته، ومتغيراته) من غير ما البرنامج نفسه يعرف. ده أساس الـ Redirection والـ Pipes.

4. wait والـ Zombies والـ Orphans

لو شفت Zombies بتتراكم، المشكلة في الـ Parent: بيعمل Children ومش بيعمل wait. وده سبب مشهور في Docker: لو البرنامج بتاعك هو PID 1 جوه الـ Container ومش بيعمل wait على الـ Children، الـ Zombies بتتراكم. والحل docker run --init (بيحط init صغير زي tini كـ PID 1).

5. الـ Signals: تكلّم Process من بره

6. fork في الحياة الحقيقية

• php-fpm: Master Process بتعمل fork لـ Workers، وكل Request بيتخدم في Worker، والـ Master بيراقبهم ويعمل fork جديد لو واحد مات.
• Nginx و PostgreSQL: نفس الفكرة: Master + Workers (PostgreSQL بيعمل Process لكل اتصال).
• Laravel Horizon: بيشغّل Worker Processes ويراقبها ويزوّد أو يقلّل عددها حسب الضغط.
• pcntl_fork() في PHP: نفس الـ fork بالظبط، متاح في CLI بس.

7. أسئلة