Procesos e hilos

📐 Fundamento

Cuando el SO crea un proceso, le asigna memoria virtual dividida en regiones:

+--------------------+ <- direcciones altas
|   Pila (stack)     |  ← variables locales, llamadas a función
|   ↓ crece hacia    |
|     abajo          |
+--------------------+
|       ...          |
+--------------------+
|   ↑ crece hacia    |
|     arriba         |
|   Heap (montón)    |  ← memoria dinámica (malloc, new)
+--------------------+
|   BSS              |  ← variables globales NO inicializadas
+--------------------+
|   Data             |  ← variables globales inicializadas
+--------------------+
|   Text             |  ← código del programa (instrucciones)
+--------------------+ <- direcciones bajas

Cada región:

• Text: las instrucciones (código compilado). Solo lectura — proteger contra que el programa se modifique a sí mismo.
• Data: globales inicializadas (int x = 5;).
• BSS: globales no inicializadas (se inicializan a 0 automáticamente).
• Heap: memoria pedida con malloc (C) o new (C++) o creada implícitamente en lenguajes de alto nivel.
• Stack: una pila por hilo (al menos una). Crece y decrece con las llamadas a función.

Además del espacio de memoria, el kernel mantiene una estructura de datos por cada proceso, llamada Process Control Block (PCB) o task_struct (en Linux).

El PCB contiene:

En Linux podés ver mucho de esto en /proc/<pid>/:

$ cat /proc/$$/status | head
Name:   bash
State:  S (sleeping)
Tgid:   12345
Pid:    12345
PPid:   12340
Uid:    1000    1000    1000    1000
...

$$ es una variable especial del shell que vale "mi propio PID".

📐 Fundamento

Un proceso pasa por varios estados durante su vida:

Transiciones más comunes:

• Nuevo → Listo: cuando el SO termina de configurarlo.
• Listo → Ejecutando: lo elige el planificador.
• Ejecutando → Listo: se le acabó el cuanto, hay otro más prioritario.
• Ejecutando → Bloqueado: llamó a read y el dato no está, espera.
• Bloqueado → Listo: llegó el dato, vuelve a la cola.
• Ejecutando → Terminado: llamó a exit().

Zombie. Estado curioso: el proceso terminó pero su PCB sigue ahí, esperando que el padre lo lea con wait(). Si el padre no lo cosecha, queda como zombie (no consume CPU pero ocupa una entrada en la tabla de procesos). Bug clásico en programas mal hechos: olvidar wait, llenar la tabla.

📐 Fundamento

En Unix, toda la creación de procesos ocurre con la syscall fork. Es una de las llamadas más fascinantes del kernel.

Qué hace fork: crea una copia exacta del proceso actual. Dos procesos idénticos quedan ejecutando el mismo código, con la misma memoria, los mismos archivos abiertos, a partir del punto donde se llamó a fork.

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

int main() {
    printf("Antes del fork. PID = %d\n", getpid());
    pid_t pid = fork();

    if (pid == 0) {
        printf("Soy el HIJO. PID = %d, padre = %d\n",
               getpid(), getppid());
    } else if (pid > 0) {
        printf("Soy el PADRE. PID = %d, hijo = %d\n",
               getpid(), pid);
    } else {
        printf("Error en fork\n");
    }

    return 0;
}

Salida típica:

Antes del fork. PID = 1234
Soy el PADRE. PID = 1234, hijo = 1235
Soy el HIJO. PID = 1235, padre = 1234

Cómo distingue padre de hijo. fork() devuelve dos veces:

• En el padre, devuelve el PID del hijo (un número positivo).
• En el hijo, devuelve 0.
• En caso de error, devuelve -1 (en el padre).

Eso es un patrón único en programación. Por eso el if (pid == 0) arriba.

Después del fork, los dos procesos son independientes: cambios en uno no se ven en el otro. Cada uno tiene su propia copia de la memoria.

Optimización: copy-on-write. Copiar toda la memoria al hacer fork sería caro. Linux usa copy-on-write (COW): ambos procesos comparten físicamente las mismas páginas hasta que uno escribe — entonces el kernel hace una copia. Si nunca se escribe, nunca se copia. Por eso fork en Linux es muy rápido aunque la memoria sea grande.

📐 Fundamento

fork te da dos procesos iguales. Pero generalmente querés que el hijo ejecute otro programa. Para eso está exec.

Qué hace exec: reemplaza la imagen del proceso actual con la de otro programa. La memoria, el PC, las pilas — todo se sustituye. El PID NO cambia.

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

int main() {
    pid_t pid = fork();

    if (pid == 0) {
        /* Hijo: reemplazar con `ls -la` */
        execlp("ls", "ls", "-la", NULL);
        /* Si llegamos acá, exec falló */
        perror("exec");
        return 1;
    } else if (pid > 0) {
        /* Padre: esperar al hijo */
        int status;
        waitpid(pid, &status, 0);
        printf("Hijo terminó con código %d\n", WEXITSTATUS(status));
    }

    return 0;
}

Cómo lo lee bash. Cuando escribís ls -la en la terminal, el shell hace exactamente esto:

1. fork() para crear un hijo.
2. En el hijo, execlp("ls", "ls", "-la", NULL) para reemplazarlo con ls.
3. En el padre, waitpid() para esperar a que ls termine.
4. Cuando termina, el padre vuelve a mostrar el prompt.

Variantes de exec:

execve es la "real" — las otras son envoltorios sobre ella.

📐 Fundamento

Wait

Cuando un proceso termina, su PCB queda hasta que el padre llame a wait() o waitpid(). Ahí el padre obtiene el estado de salida y libera el PCB.

int status;
pid_t hijo = wait(&status);  /* espera CUALQUIER hijo */
if (WIFEXITED(status)) {
    int code = WEXITSTATUS(status);
    printf("Hijo %d terminó normalmente con código %d\n", hijo, code);
} else if (WIFSIGNALED(status)) {
    int sig = WTERMSIG(status);
    printf("Hijo %d murió por señal %d\n", hijo, sig);
}

Si el padre no llama wait, el hijo queda zombie. Si el padre muere antes, los hijos son adoptados por PID 1 (init/systemd), que sí los cosecha.

IPC — comunicación entre procesos

Ya vimos que cada proceso tiene su memoria privada. ¿Cómo se comunican? Mecanismos de IPC (Inter-Process Communication):

Pipes (las más usadas en shell):

$ ls | grep .txt

Bash:

1. Hace dos forks (uno para ls, otro para grep).
2. Crea una pipe.
3. Conecta stdout del primero a stdin del segundo.
4. Espera ambos.

El kernel garantiza el buffer intermedio. Si grep lee lento, ls se bloquea hasta que haya espacio. Si grep no lee y la pipe se llena, ls espera.

📐 Fundamento

Un hilo (thread) es como un proceso, pero comparte memoria con otros hilos del mismo proceso.

Comparación:

Modelo mental. Un proceso es una casa: paredes, instalaciones, sus propios muebles. Un hilo es una persona dentro de esa casa: hace su tarea, comparte la cocina y los muebles con los demás hilos. Varias casas (procesos) son completamente independientes; varias personas dentro de la misma casa (hilos) tienen que negociar.

Para qué los hilos. Permiten concurrencia dentro de un programa sin pagar el precio de procesos separados. Casos típicos:

• Un servidor web atiende a 1000 clientes con 1000 hilos en lugar de 1000 procesos.
• Tu navegador renderiza una página en un hilo mientras descarga imágenes en otros.
• Un editor de video procesa cada frame en paralelo.

Crear un hilo en C (POSIX threads):

#include <pthread.h>
#include <stdio.h>

void *trabajo(void *arg) {
    int n = *(int *)arg;
    for (int i = 0; i < 5; i++) {
        printf("Hilo %d, iteración %d\n", n, i);
    }
    return NULL;
}

int main() {
    pthread_t h1, h2;
    int a = 1, b = 2;
    pthread_create(&h1, NULL, trabajo, &a);
    pthread_create(&h2, NULL, trabajo, &b);
    pthread_join(h1, NULL);
    pthread_join(h2, NULL);
    return 0;
}

pthread_create lanza un hilo. pthread_join espera (equivalente a wait para procesos).

En Python (más fácil):

import threading

def trabajo(n):
    for i in range(5):
        print(f"Hilo {n}, iter {i}")

h1 = threading.Thread(target=trabajo, args=(1,))
h2 = threading.Thread(target=trabajo, args=(2,))
h1.start(); h2.start()
h1.join(); h2.join()

Nota: Python tiene un detalle famoso llamado GIL (Global Interpreter Lock) que impide que dos hilos ejecuten Python real en paralelo. Para CPU-bound usá multiprocessing o lenguajes sin GIL. Para I/O-bound, threading está bien.