Sistemas operativos modernos

En caso contrario (por ejemplo, en System V y Solaris), el kemel deberá efectuar algo de traba­ jo. Ya hablamos en general de los subprocesos en el capítulo 2. Aquí sólo haremos unos cuan­ tos comentarios acerca de los subprocesos de kemel en UNIX. Lo que más debe cuidarse al introducir subprocesos es mantener la semántica correcta tra­ dicional de UNIX. Consideremos primero fork. Supongamos que un proceso con múltiples sub­ procesos (de kemel) ejecuta una llamada al sistema fork. ¿Todos los demás subprocesos deberán crearse en el nuevo proceso? Por el momento, contestemos en sentido afirmativo esta pregunta. Supongamos que uno de los otros subprocesos estaba bloqueado al leer del teclado. ¿El subpro­ ceso correspondiente en el nuevo proceso también debe estar bloqueado al leer del teclado? Si así fuera, ¿cuál de ellos obtendrá la siguiente línea que se teclee? Si no fuera así, ¿qué deberá es­ tar haciendo ese subproceso en el nuevo proceso? El mismo problema se presenta con muchas otras cosas que pueden hacer los subprocesos. En un proceso de un solo subproceso este proble­ ma no surge, porque el único subproceso no puede estar bloqueado cuando invoca a fork. Con­ sideremos ahora el caso en que ’»^5 otros subprocesos no se crean en el proceso hijo. Supongamos que uno de esos subprocesos tiene un mutex que el único subproceso del nuevo proceso trata de obtener después del fork. El mutex nunca se liberará y el subproceso quedará suspendido por tiempo indefinido. Hay muchos otros problemas para los que no hay una solución sencilla. La E/S de archivos es otra área problema. Supongamos que un subproceso se bloquea le­ yendo de un archivo y otro subproceso cierra el archivo o efectúa Iseek para cambiar de lugar del apuntador de archivo actual. ¿Qué sucederá a continuación? ¿Quién sabe? El manejo de señales es otro asunto escabroso. ¿Las señales deben dirigirse a un subproce­ so específico o al proceso en general? Lo más probable es que una excepción de punto flotante (SIGPFE) deba ser atrapada por el subproceso que la causó. ¿Qué pasa si no la atrapa? ¿Debe­ rá eliminarse sólo ese subproceso o todos los subprocesos? Consideremos ahora la señal SIGINT, generada por el usuario en el teclado. ¿Cuál subproceso debe atraparla? ¿Todos los subprocesos deben compartir un mismo conjunto de máscaras de señales? Todas las soluciones a estos y otros problemas, por lo general, hacen que algo falle en algún lado. Lograr que la se­ mántica de subprocesos (por no mencionar el código) sea correcta no es una cuestión trivial. Subprocesos en Linux Linux soporta subprocesos de kemel de una manera interesante que vale la pena examinar. La implementación se basa en ideas de 4.4BSD, pero los subprocesos de kemel no se habilitaron en esa distribución porque Berkeley se quedó sin dinero antes de que pudiera rescribirse la bi­ blioteca de C para resolver los problemas arriba mencionados. El meollo de la implementación de subprocesos en Linux es una nueva llamada al sistema, clone, que no está presente en ninguna otra versión de UNIX. El formato de la invocación es: pld = clone(función, apunt_pila, indicadores_compart, arg); La llamada crea un nuevo subproceso, ya sea en el proceso actual o en uno nuevo, dependiendo de indicadores^compart. Si el nuevo subproceso está en el proceso actual, compartirá el espa­ cio de direcciones con los subprocesos existentes y las siguientes escrituras de cualquier byte del espacio de direcciones, realizada por cualquier subproceso será visible de inmediato para los