Buenas preguntas. La identificación del trabajo es básicamente una construcción de caparazón. Hay soporte en el núcleo en forma de señales que están involucradas en el control del trabajo, y la forma en que el kernel sabe exactamente a qué procesos enviar las señales de control del trabajo.
Estrictamente hablando, la respuesta a su primera pregunta es que la identificación del trabajo es puramente una creación de shell. Existe porque una canalización (o, raramente, otra construcción agrupada de shell) puede consistir en procesos múltiples que se deben controlar como una unidad.
Para responder a su última pregunta, el shell inicia todos los procesos primero haciendo un fork(2) y luego haciendo un execve(2). La única diferencia con & es que el shell no hace un wait(2) (o una variante relacionada) y entonces el programa puede continuar "en segundo plano". En realidad, hay poca distinción en Unix entre el primer plano y el fondo.
El grupo de procesos es una asociación definida por shells para que el kernel conozca un solo proceso de "primer plano" que maneje un conjunto de varios procesos de "fondo". Esto es principalmente importante para que los procesos en segundo plano generen una señal en caso de que decidan leer de repente desde un terminal. (Tal terminal probablemente esté conectado a la entrada estándar.) Esto hará que el "trabajo" genere una señal y el shell pedirá al usuario que haga algo.
Pruebe (sleep 5; read x)& y después de 6 segundos escriba un retorno o algo así para que la cáscara se despierte. Fue entonces cuando se ve algo así como ...
[1] + Stopped (sueño 5; leer x)
... y, a continuación, escriba fg de llevarlo a cabo en el primer plano.
Originalmente, Unix tenía tuberías, y tenía &, pero no había forma de mover un comando o tubería entre el primer plano y el fondo y no había forma de ayudar a un proceso en segundo plano que de repente decidió leer la entrada estándar.
El control de trabajos y el soporte del kernel para él fueron agregados por Bill Joy y otros en las primeras versiones de BSD y csh (1). Estos fueron recogidos línea por línea por Unix comercial y en clonados para el kernel de Linux similar al del trabajo.
En cuanto a las preguntas acerca de los grupos de procesos y ps(1) ... Con el fin de apoyar el control de trabajos en conchas, el estado del proceso del núcleo incluye un ID de grupo y un identificador de sesión. Un grupo de proceso y un trabajo son lo mismo, pero un número de trabajo es solo un identificador del shell. Un proceso es un líder de sesión si el ID de sesión es el mismo que el pid, y un proceso es un líder de grupo de proceso si el pgid es el mismo que el pid.Creo que está sucediendo algo un poco más sutil con el + que imprime ps(1). Cada terminal sabe cuál es su grupo de procesos en primer plano, por lo que creo que un proceso obtiene un + si pid == pgid & & (pgid es la página de primer plano para su terminal de control).
En resumen, el kernel mantiene varios elementos de estado: pid, pgid, sid, y un proceso puede tener un terminal de control y un terminal puede tener un pgid de primer plano. Estas credenciales están principalmente destinadas a admitir el control del trabajo, pero también se utilizan para revocar el acceso a un terminal cuando el usuario cierra la sesión.
En nuestro ejemplo para grupo de procesos, ¿cuál es el uso del grupo de procesos? Por favor, explique en detalle cómo está involucrado el grupo de procesos. – avd
Una cosa más, has escrito que el proceso en primer plano controla los procesos en segundo plano, ¿puedes darme un ejemplo de esto? – avd
Disculpe una duda más, escribió que el ID de trabajo está integrado en shell, por lo que el primer plano/fondo es la comprensión del shell pero cuando lo hacemos "ps" aparece en las estadísticas como "R" o "R +" como primer plano pero ps es ejecutado por kernel entonces, ¿cómo sabe kernel que el trabajo está de vuelta/en primer plano? – avd