anchor.diff:  == IO
   
   Si pensamos en algún servidor web, veremos que la parte de IO resulta fundamental a la hora
  -de manejar multiples requests. Estamos leyendo request data por medio de la red, enviando el
  -response para esa request e incluso leyendo archivos desde disco para servir contenido estático.
  +de manejar multiples requests. Al estar leyendo los datos de esa request por medio de la red, enviando el
  +response de la misma o incluso leyendo archivos desde disco para servir contenido estático.
   
   *Es util pensar a las operaciones de IO en dos etapas*
   
   * No hay datos o están en el controller -> Los *_datos están disponibles_* para el kernel.
   * Datos en los buffers del kernel -> Datos en la memoria de la aplicación.
   
  -*La primera etapa de chequeo del dispositivo puede ser blocking o non-blocking, y la segunda de transmicion de
  +*La primera etapa de chequeo del dispositivo puede ser blocking o non-blocking, y la segunda de transmisión de
   los datos puede ser synchronous o asynchronous.*
   
  -Otra aclaración importante es que significa que los *_datos están disponibles_* y esto va
  +Una aclaración importante es que significa que los *_datos están disponibles_* y esto va
   a depender de la información que estemos leyendo.
   
   * UDP: Un datagrama entero fue recibido.
  
positive.code: 
  Un proceso ejecuta instrucciones en dos modos distintos, ya sea a nivel de aplicación o a nivel de kernel, ya
  que ciertas acciones necesitan mas privilegios que otras. Esto para el usuario es transparente pero hacer el switch
  de un modo al otro es costo.
  
  * *Kernel mode:* El código que se esta ejecutando tiene acceso completo e ilimitado al hardware subyacente.
  Este puede ejecutar cualquier instrucción y referenciar cualquier dirección de memoria. Este modo es reservado
  funciones de bajo nivel del sistema operativo. Cualquier crash en este nivel seria catastrófico y detendría la PC.
  
  * *User Mode:* El código que se esta ejecutando no tiene la capacidad de acceder a hardware o memoria sin delegar estas
  acciones en una llamado a un API del sistema (system call). Debido a esta separación los crash a este nivel son
  recuperables, la mayoría del código se ejecuta en este nivel.
  
  image::images/ProtectionRings.png[]
  
  == Models
  
  Iremos explicando cada modelo junto con una imagen y las descripción de lo que sucede.
  
  _Nota: Las imágenes son de un ejemplo de socket UDP ya que el concepto de data being "ready" es mas simple_
  
  
negative.code: 
  image::images/IOMultiplexing.png[]
  
  En el ejemplo de arriba hacemos el block en el llamado al _select_, esperando a que el datagrama este listo para ser leído.
  Cuando el _select_ retorna esto indica que el socket es "readable", entonces podemos llamar a _recvfrom_ para copiar el datagrama
  en el buffer de nuestra aplicación.
  
  ===== Comparing to the blocking I/O model
  Si comparamos la figura del modelo 1 y la del 3:
  
  * Ventajas: Podemos monitorear mas de un descriptor hasta que alguno este listo.
  * Desventajas: Usando el _select_ requiere dos system calls _(select y recvfrom)_ en lugar de un solo llamado.
  
  ===== Multithreading with blocking I/O
  