ASO AV
|
|
Título del Test:
![]() ASO AV Descripción: Tests de ASO del Aula Virtual |



| Comentarios |
|---|
NO HAY REGISTROS |
|
¿Cómo hay que invocar a la llamada al sistema sbrk() para que nos devuelva dónde se encuentra actualmente el límite de la memoria dinámica?. sbrk(0). sbrk(GET_CURRENT). Indica cuál de las siguientes afirmaciones sobre tuberías es cierta. Una tubería sirve para comunicar dos procesos (un productor y un consumidor) por medio de un buffer en memoria de tamaño limitado. Una tubería sirve para comunicar dos procesos (un productor y un consumidor) por medio de un fichero temporal intermedio en disco. ¿Podemos hacer que un proceso padre con un fichero abierto cree un hijo con fork(), y que tanto el hijo como el padre recorran dicho fichero por un lugar diferente cada uno?. Aunque el hijo use el descriptor heredado del padre, no hay problema, ya que cada descriptor apunta a una entrada diferente de la tabla de ficheros abiertos y eso da offsets independientes. Para poder tener dos recorridos sobre el mismo fichero, uno de los dos tendría que abrir de nuevo el fichero para que se le asignara una nueva entrada en la tabla de ficheros abiertos y tener así su propio offset. Al ejecutar un fork(), si la salida es -1... Sólo el padre recibe el valor negativo y puede detectar el fallo. Ambos, padre e hijo reciben el error. Si un padre reserva con malloc() una zona de memoria que se asigna al puntero p, un hijo que después genera con fork()... Tanto el padre como el hijo pueden ver la memoria a la que apunta p, y después del fork() ambos ven las modificaciones que haga el otro en la memoria a la que apunta p. Tanto el padre como el hijo pueden ver la memoria a la que apunta p, pero las modificaciones del padre no las ve el hijo (y viceversa) después del fork(). Un proceso padre crea una tubería y a continuación crea dos hijos. ¿Podría utilizar la misma tubería para enviar datos a ambos hijos a la vez?. Claro. Una tubería es como un canal de comunicación donde cualquier número de procesos pueden escribir en uno de los extremos y cualquier número de procesos pueden leer del otro, siempre y cuando la tubería sea la misma heredada de un padre común. No, no se puede. Una tubería solamente permite la comunicación entre dos procesos: uno productor y otro consumidor. Si un proceso modifica una variable de su entorno... a partir de ese momento, los nuevos hijos recibirán una copia de la nueva variable, pero los hijos ya creados no verán el cambio. se modifica la misma variable de entorno de todos sus hijos, ya que cada hijo recibe un puntero al entorno del padre. De esta manera es posible cambiar una variable de entorno en todos los hijos a la vez. Si cuando estamos escribiendo en una zona de memoria reservada con malloc() nos salimos ligeramente del espacio reservado, ¿cuál de las dos situaciones que se indican a continuación es más probable que suceda?. El sistema de gestión de memoria se corromperá y en algún momento en otra parte de nuestro programa nos dará un error, se colgará el proceso, o dará una excepción de protección de memoria, pero probablemente no nos servirá para determinar el origen de nuestro error. Una excepción de protección de memoria (también llamada violación de segmento o segmentation fault) se produce en cuanto nos salimos de la zona reservada, lo que nos permitirá depurar el error con facilidad. Cuando un proceso ejecuta fork(), genera un hijo que hereda una copia de los descriptores del padre, sin embargo... estos descriptores los pierde en el momento en que llama a la función execve() u otra de su familia. a pesar de que cada uno tiene su propia copia de los descriptores, los offsets de los ficheros a los que apuntan seguirán actualizándose adecuadamente sea quien sea el que se mueva por ellos. Indica cuál de las siguientes afirmaciones relativas a la gestión de la memoria dinámica es correcta. El uso de malloc() y free() puede llegar a provocar fragmentación en la memoria disponible, y por tanto, podría darse el caso de que teniendo memoria suficiente no hubiera ningún hueco del tamaño solicitado. El uso de malloc() y free() no produce fragmentación en la memoria dinámica porque cuando no se encuentra un hueco del tamaño solicitado habiendo suficiente memoria disponible, se mueven todas las zonas de memoria reservadas al comienzo de la memoria dinámica para acumular todos los huecos al final y poder hacer uso de la memoria libre total. Los siguientes códigos son equivalentes suponiendo que no hay errores: int fh = open("fichero", ...); dup2(fh, STDOUT_FILENO); close(fh); printf("Hola\n"); y: close(STDOUT_FILENO); open("fichero", ...); write(STDOUT_FILENO, "Hola\n", 5);. Falso. Verdadero si STDIN_FILENO no está cerrado. Si queremos saber el tamaño de un fichero abierto fh con la llamada lseek, podemos escribir: off_t tam = lseek(fh, 0, SEEK_CUR);. off_t tam = lseek(fh, 0, SEEK_END);. La llamada realloc() nunca llama a brk()/sbrk()... Falso. Verdadero, sólo la llama malloc(). Si un proceso modifica una variable de su entorno ... a partir de ese momento, los nuevos hijos recibirán una copia de la nueva variable, pero los hijos ya creados no verán el cambio. se modifica la misma variable de entorno de todos sus hijos, ya que cada hijo recibe un puntero al entorno del padre. De esta manera es posible cambiar una variable de entorno en todos los hijos a la vez. Si un proceso tiene que crear otros dos que usarán una tubería para comunicarse entre ellos, ¿quién sería el encargado de crear dicha tubería?. Cuando un hijo crea una tubería, es inmediatamente accesible para sus hermanos. Por eso simplemente cada hijo crea una tubería y configura sus extremos para que se adapten al papel de productor o consumidor de la comunicación. El padre de ambos procesos es quien la crea. Cada uno de los hijos la configurará para adaptarla a su rol en la comunicación. Las tuberías (pipe) se pueden utilizar, además de para comunicar los procesos, para sincronizarlos. ¿Cómo?. A través de la espera síncrona de las funciones read() y write(). No se utiliza para sincronización, sólo para comunicación. ¿Cómo hay que invocar a la llamada al sistema sbrk() para que nos devuelva dónde se encuentra actualmente el límite de la memoria dinámica ?. sbrk(0). sbrk(GET_CURRENT). Con respecto a la llamada wait() y el valor status que recibe dicha llamada... status codifica el motivo de la terminación del proceso hijo, pero wait() no permite indicar a qué proceso hijo espera. status codifica el motivo de la terminación del proceso hijo que se le ha pasado como parámetro a wait(). Al ejecutar un fork(), si la salida es -1 ... Sólo el padre recibe el valor negativo y puede detectar el fallo. Ambos, padre e hijo reciben el error. ¿Qué sucede si matamos al padre de un número de procesos?. Todos los procesos hijos mueren también. Los procesos hijos quedarán huérfanos y serán adoptados por init/systemd. En Linux, para cada proceso, las señales se implementan y gestionan mediante. Dos vectores de bits que permiten controlar las señales pendientes y bloqueadas. Tres vectores de bits que permiten controlar las señales ignoradas, pendientes y bloqueadas. En Linux la llamada al sistema fork() se sustituye por clone() que solamente crea nuevos hilos, entonces ¿cómo se consigue tener la funcionalidad de crear procesos e hilos con esta nueva llamada?: Los parámetros de clone() permiten configurar el grado de compartición de elementos del hilo padre, de manera que no hay solo una creación de un proceso como con fork() o un hilo, sino que también son posibles toda una gama de combinaciones intermedias entre ambos. La llamada clone() recibe en uno de sus parámetros si tiene que comportarse como un fork() y crear un proceso hijo a partir del proceso padre con una copia de todos los recursos del padre, o como un execv() y cargar un nuevo programa en la memoria del proceso padre. Una tarea en Linux se insertaría en la cola 120 del planificador de Linux denominado O(1). Indica cuál de los siguientes es un motivo para que la tarea suba o baje de cola. El único mecanismo que permite a una tarea subir y bajar entre las colas de prioridad es la utilización de la orden nice, bien por el usuario, al que solo se le permite bajar la prioridad de la tarea, o bien por el administrador, que puede subirla o bajarla. Según el comportamiento que haya tenido una tarea durante el consumo de su quantum, al pasar de tarea activa a expirada puede ir a parar a una cola diferente. Con respecto a la gestión de procesos en Linux y Windows: La creación de procesos en Windows es más rápida que en Linux porque no nececesita hacerse en modo núcleo gracias a la biblioteca Win32. Sin la copia en escritura, la cantidad de memoria física ocupada por los procesos sería mayor y el tiempo invertido en crear un proceso hijo con fork() también se incrementaría. Respecto a la planificación de procesos en Windows: Un hilo que realiza E/S es penalizado y su prioridad se disminuye por bloquearse mucho y hacer poco uso de la CPU. Cuando un hilo priorizado consume su quantum de tiempo, se baja su prioridad hasta llegar a su prioridad base. En Linux, respecto al tratamiento de señales: Una señal bloqueada no puede ser enviada en este momento al proceso, pero cuando se desbloquee dicha señal será enviada al proceso. Una señal bloqueada no puede ser enviada al proceso y, si se envía al proceso, esta señal es ignorada y no se recuerda que fue enviada al proceso. En Linux la señal SIGKILL: Provoca la muerte inmediata del proceso que la recibe, independientemente de si está bloqueado o suspendido. Como cualquier otra señal, solo puede gestionarse si el proceso está en ejecución, así que aunque esté bloqueado o suspendido, el núcleo cambia el estado del proceso a ready y cuando el planificador le asigne CPU, el núcleo se encargará de matar al proceso. Linux llama tareas a los hilos, y la estructura task_struct es el equivalente a un PCB, conteniendo información vital para la tarea. Indica qué información de entre las siguientes no se conserva en esta estructura: El puntero a la pila del kernel, porque no pertenece a la tarea, sino al núcleo del sistema operativo y por tanto se mantiene aparte. La tabla de ficheros abiertos, ya que realmente es una estructura global. Con respecto a los procesos en Windows: La prioridad de un hilo en Windows depende solamente de la prioridad del proceso que lo contiene. A diferencia de Linux, en Windows existe el concepto de proceso y de hilo. Cuando se crea un proceso hijo mediante la llamada a fork(), indica cuál de los siguientes elementos no hereda el hijo del padre. El vector de señales pendientes. Tabla de descriptores de ficheros. Una tarea en Linux se insertaría en la cola 120 del planificador de Linux denominado O(1). Indica cuál de los siguientes es un motivo para que la tarea suba o baje de cola. El único mecanismo que permite a una tarea subir y bajar entre las colas de prioridad es la utilización de la orden nice, bien por el usuario, al que solo se le permite bajar la prioridad de la tarea, o bien por el administrador, que puede subirla o bajarla. Según el comportamiento que haya tenido una tarea durante el consumo de su quantum, al pasar de tarea activa a expirada puede ir a parar a una cola diferente. En Linux la señal SIGKILL : Provoca la muerte inmediata del proceso que la recibe, independientemente de si está bloqueado o suspendido. Como cualquier otra señal, solo puede gestionarse si el proceso está en ejecución, así que aunque esté bloqueado o suspendido, el núcleo cambia el estado del proceso a ready y cuando el planificador le asigne CPU, el núcleo se encargará de matar al proceso. En la implementación del envío de señales en Linux. el kernel sirve todas las señales que estén pendientes para ese proceso. el kernel sirve todas las señales que estén pendientes que se tengan que ejecutar en modo núcleo, pero solamente servirá una de las que estén pendientes para ejecutarse en modo usuario. En Linux, el planificador CFS (Completely Fair Scheduling) elige el proceso: Que tenga mayor prioridad. Que menor tiempo virtual tenga. En Linux , para cada proceso, las señales se implementan y gestionan mediante. Dos vectores de bits que permiten controlar las señales pendientes y bloqueadas. Tres vectores de bits que permiten controlar las señales ignoradas, pendientes y bloqueadas. Linux llama tareas a los hilos, y la estructura task_struct es el equivalente a un PCB, conteniendo información vital para la tarea. Indica qué información de entre las siguientes no se conserva en esta estructura: El puntero a la pila del kernel, porque no pertenece a la tarea, sino al núcleo del sistema operativo y por tanto se mantiene aparte. La tabla de ficheros abiertos, ya que realmente es una estructura global. Cuando se crea un proceso hijo mediante la llamada a fork(): El proceso hijo hereda los descriptores de ficheros del padre y el valor de todas las variables del padre salvo el valor devuelto por fork() que es diferente. Los procesos padre e hijo comparten los descriptores de ficheros del padre, las señales capturadas y todas las variables del padre. Con respecto a los procesos en Windows: La prioridad de un hilo depende tanto del propio hilo como del proceso al que pertenece. Al igual que en Linux, en Windows no existe el concepto de proceso, sino que solamente se crean hilos. Un grupo de hilos relacionados se trata como un proceso y un grupo de procesos relacionados se denomina un Job. En el PCB de un proceso se almacena: Un puntero a la tabla de páginas y un puntero a la tabla de nodos-i abiertos por el proceso. Un puntero a la tabla de páginas y una copia de los registros de la máquina. Windows para cada proceso define un working-set (conjunto de trabajo) que es un: Conjunto de páginas usadas con más frecuencia, la mayoría de ellas cargadas en memoria pero algunas de ellas están en un fichero de paginación y se cargarán al producirse un fallo de página. Conjunto de páginas que están en memoria y que pueden referenciarse sin un fallo de página. En el caso concreto de Linux y el formato de ejecutable ELF: El ejecutable con todas las dependencias resueltas, salvo los símbolos que dependen de bibliotecas dinámicas, lo construyen el compilador y el enlazador estático. Al cargarse en memoria, el enlazador dinámico (ld-linux.so) se encarga de resolver los símbolos faltantes e incluir la dirección adecuada en el código. No es posible crear un ejecutable libre de símbolos dinámicos porque actualmente todas las bibliotecas que usa el compilador son dinámicas, haciendo necesario emplear siempre el enlazador dinámico (ld-linux.so) para ajustar el código a las direcciones de memoria donde se ha copiado en el mapa de memoria del proceso. En el formato ELF, el tipo de fichero binario objeto compartido se corresponde con: Ficheros .o que necesitan ser procesados por el enlazador antes de poder cargarse y ejecutarse. Bibliotecas compartidas con símbolos para el enlazador y código directamente ejecutable en tiempo de ejecución. Como las bibliotecas dinámicas se mapean en la memoria de todos los procesos que las necesitan... Se mapean en cada proceso en una dirección de memoria virtual que puede ser diferente, si la biblioteca está compilada para generar PIC. Se mapean en todos los procesos en la misma dirección de memoria virtual si están compiladas para generar PIC. Con respecto a los ficheros proyectados en memoria: No se usan frecuentemente porque aumentan el número de llamadas al sistema para acceder al fichero. Aprovechan la memoria virtual para ir cargando partes del fichero bajo demanda. Con respecto a la memoria virtual, el segmento de código de un proceso Linux... Se encuentra asociado directamente al código del fichero ejecutable, de manera que si se produce un fallo de página virtual, el contenido se obtendrá del propio ejecutable. Cuando se crea el proceso, se copia el código del ejecutable a la zona de intercambio para que se vaya cargando bajo demanda conforme se producen fallos de página virtual. En el algoritmo de colegas (buddy algorithm) que usa el kernel de Linux para reservar memoria interna, nos encontramos con que tenemos 64 marcos contiguos en total, donde los libres están en texto normal y los ocupados en negrita: 32|16|8|8. ¿Se podrían reservar 40 marcos contíguos de memoria?. No. Sí. Dividimos el bloque de 16 en dos bloques de 8 y tomamos el bloque de 32 más los 8 siguientes para formar un bloque de 40. Windows gestiona la memoria virtual creando: Un VAD (virtual address descriptor) con información sobre el rango de direcciones mapeadas, la sección del fichero mapeada, offset, y permisos. Un PFD (Page Frame Database) con información sobre el uso de los marcos de página física, su estado, sus permisos y un puntero a la tabla de páginas correspondiente al mapeo. En la gestión de memoria de los procesadores Intel de 32 bits, si quisiéramos reducir el tamaño del directorio de páginas para que tuviera solamente 128 entradas, sin tocar el tamaño de página, ¿cuántos marcos físicos ocuparía cada tabla de páginas que cuelga de dicho directorio?. 4. 8. En Windows, si un proceso accede a una de las páginas incluidas en su working set: aún perteneciendo al working set, podría producirse un fallo de página. siempre se producirá un acierto de página. En la gestión de memoria de los procesadores Intel de 32 bits, si quisiéramos reducir el tamaño del directorio de páginas para que tuviera solamente 128 entradas, sin tocar el tamaño de página, ¿cuántos marcos físicos ocuparía cada tabla de páginas que cuelga de dicho directorio ?. 4. 8. En Windows, si un proceso accede a una de las páginas incluidas en su working set : aún perteneciendo al working set, podría producirse un fallo de página. siempre se producirá un acierto de página. Windows para cada proceso define un working-set (conjunto de trabajo) que es un : Conjunto de páginas usadas con más frecuencia, la mayoría de ellas cargadas en memoria pero algunas de ellas están en un fichero de paginación y se cargarán al producirse un fallo de página. Conjunto de páginas que están en memoria y que pueden referenciarse sin un fallo de página. En el formato ELF, el tipo de fichero binario objeto compartido se corresponde con : Ficheros .o que necesitan ser procesados por el enlazador antes de poder cargarse y ejecutarse. Bibliotecas compartidas con símbolos para el enlazador y código directamente ejecutable en tiempo de ejecución. Con respecto a la memoria virtual, el segmento de código de un proceso Linux... Se encuentra asociado directamente al código del fichero ejecutable, de manera que si se produce un fallo de página virtual, el contenido se obtendrá del propio ejecutable. Cuando se crea el proceso, se copia el código del ejecutable a la zona de intercambio para que se vaya cargando bajo demanda conforme se producen fallos de página virtual. En una arquitectura de 32 bits, el esquema de paginación de 4 niveles usado por Linux se usa así: Los campos Global dir y table se componen de 10 bits, mientras que upper dir y middle dir no se usan. Los campos Global dir y upper dir se componen de 10 bits, mientras que middle dir y table no se usan. En el caso concreto de Linux y el formato de ejecutable ELF : El ejecutable con todas las dependencias resueltas, salvo los símbolos que dependen de bibliotecas dinámicas, lo construyen el compilador y el enlazador estático. Al cargarse en memoria, el enlazador dinámico (ld-linux.so) se encarga de resolver los símbolos faltantes e incluir la dirección adecuada en el código. No es posible crear un ejecutable libre de símbolos dinámicos porque actualmente todas las bibliotecas que usa el compilador son dinámicas, haciendo necesario emplear siempre el enlazador dinámico (ld-linux.so) para ajustar el código a las direcciones de memoria donde se ha copiado en el mapa de memoria del proceso. En Linux, la labor del demonio pdflush: es escribir en disco las páginas modificadas más antiguas. es comprobar si hay suficientes marcos de páginas libres, y si no hay, empezar a recuperar marcos ocupados por los procesos. Con respecto a los ficheros proyectados en memoria: No se usan frecuentemente porque aumentan el número de llamadas al sistema para acceder al fichero. Aprovechan la memoria virtual para ir cargando partes del fichero bajo demanda. Indica cuál de las siguientes afirmaciones es verdadera respecto a la labor del SO cuando sitúa el código de un ejecutable en memoria: El SO no tiene que hacer nada puesto que los ejecutables se compilan siempre para generar código independiente de la posición (PIC) que permite situarlo en cualquier lugar de la memoria virtual del proceso. El SO puede encontrarse con que el código tiene direcciones de memoria que se determinarán cuando se construya el mapa de memoria de proceso, por lo que tiene que adaptar dichas direcciones del código a la posición concreta donde lo ha situado. Respecto a los grupos de bloques usados por Ext2, Ext3 y Ext4: Cada grupo contiene unos bloques de disco reservados que se usan para el journaling de dichos sistemas de ficheros. Cada grupo contiene una copia del superbloque, unos descriptores de grupo, un bloque con el mapa de bits de bloques del grupo, un bloque con el mapa de bits de nodos-i del grupo, varios bloques de nodos-i y bloques de datos. Con respecto a la comunicación de la CPU con el hardware de E/S: En la arquitectura Intel solamente se permite comunicación por medio de las órdenes in/out, no permitiéndose la comunicación por mapeo de memoria. El tener procesadores con arquitecturas de 64 bits permite poder usar más fácilmente la E/S mapeada en memoria, debido al enorme rango de direcciones disponibles que hacen que reservar un rango para E/S no sea un problema. Con respecto a la jerarquía de directorios de Windows... A diferencia de Linux, el kernel no mantiene un árbol virtual único que establezca una jerarquía de directorios permitiendo acceder a todos los sistemas de ficheros montados, sino que cada unidad recibe una letra diferente y tiene su propio árbol de directorios aislado. Para acceder a un fichero dada su ruta, es necesaria una traducción de la notación antigua, mantenida por compatibilidad usando letras como nombres de unidad, a la verdadera jerarquía de directorios. Suponga que hacemos un cambio al sistema de ficheros de UNIX tradicional y hacemos que los directorios guarden también los metadatos de los ficheros (tamaño, permisos, etc.). ¿Qué operaciones se acelerarían?. Las llamadas al sistema read y write. Algunas operaciones de listado de ficheros. Un segmento de los sistemas de ficheros basados en log contiene: Bloques de nodos-i, directorios, pero no bloques de datos que se guardan en zonas específicas del sistema de ficheros. Bloques de nodos-i, directorios y bloques de datos. La MFT de NTFS se mantiene como un fichero especial. Verdadero, se reparte por toda la partición del disco y puede crecer hasta tener 2^48 entradas. Verdadero, se mantiene siempre al principio de la partición del disco y no puede crecer más de un límite fijado al formatear el sistema de ficheros. En el sistema de ficheros NTFS de Windows, la MFT: Se descompone en registros. Cada registro describe un fichero o un directorio, y almacena los metadatos de los mismos. Su registro 0 se encuentra en el sector de arranque. Si en un sistema de ficheros Ext3, un nodo-i tiene 12 direcciones para bloques de datos, un BSI, un BDI y un BTI. Si las direcciones son de 4 bytes y cada bloque de disco es de 1~KiB, el tamaño máximo de fichero es: De aproximadamente un 1 GiB. De aproximadamente 16 GiB. Indica cuál de las siguientes secuencias de operaciones de una bitácora son idempotentes: Inicializar un nodo-i y marcar como ocupado en la correspondiente entrada del mapa de bits de nodos-i. Añadir un nombre de fichero al final de un directorio y marcar como libre un bloque de datos en el mapa de bits de bloques de datos. Las asociaciones entre nombre y nodo-i contenidas en un directorio se encuentran: En el nodo-i del directorio. En los bloques de datos del directorio. Un segmento de los sistemas de ficheros basados en log contiene : Bloques de nodos-i, directorios, pero no bloques de datos que se guardan en zonas específicas del sistema de ficheros. Bloques de nodos-i, directorios y bloques de datos. Bloques de nodos-i, directorios y bloques de datos. Las escrituras. Las lecturas. Respecto a los sistemas de ficheros Ext4 y NTFS: Ext4 soporta ficheros con agujeros, pero NTFS no. Ambos soportan ficheros con agujeros. En el sistema de ficheros NTFS de Windows, la MFT: Se descompone en registros. Cada registro describe un fichero o un directorio, y almacena los metadatos de los mismos. Su registro 0 se encuentra en el sector de arranque. La MFT de NTFS se mantiene como un fichero especial . Verdadero, se reparte por toda la partición del disco y puede crecer hasta tener 2^48 entradas. Verdadero, se mantiene siempre al principio de la partición del disco y no puede crecer más de un límite fijado al formatear el sistema de ficheros. En ext3, al hacer `ls -l` se muestra el tamaño de cada fichero. Este tamaño está almacenado: En los bloques de datos del directorio. En el nodo-i de cada fichero. Con respecto a la comunicación de la CPU con el hardware de E/S : En la arquitectura Intel solamente se permite comunicación por medio de las órdenes in/out, no permitiéndose la comunicación por mapeo de memoria. El tener procesadores con arquitecturas de 64 bits permite poder usar más fácilmente la E/S mapeada en memoria, debido al enorme rango de direcciones disponibles que hacen que reservar un rango para E/S no sea un problema. Los sistemas de ficheros basados en log son normalmente incompatibles con los sistemas de ficheros convencionales: Son incompatibles porque un segmento puede incluir bloques de nodos-i, datos y de metadatos mezclados. Porque incluyen un fichero aparte para almacenar el log. En Linux: El sistema de ficheros Ext2 está organizado en grupos de bloques con nodos-i propios. El Virtual File System impide que los volúmenes de red estén montados bajo la misma raíz del sistema de ficheros. Suponga que hacemos un cambio al sistema de ficheros de UNIX tradicional y hacemos que los directorios guarden también los metadatos de los ficheros (tamaño, permisos, etc.). ¿Qué operaciones se acelerarían ?. Las llamadas al sistema read y write. Algunas operaciones de listado de ficheros. La llamada al sistema void exit (int status): Deja al proceso en estado zombie si el proceso padre no esta esperando en la llamada wait(). Hace que la CPU salga del proceso pero este sigue ocupando espacio de memoria con el texto, los datos y la pila del proceso hasta que el padre ejecuta la llamada wait(). |





