scala - reales - libro de android studio en español pdf

Futuros de Scala: ¿cuál es el hilo principal que se espera que hagan los futuros mientras se ejecutan?

Question

Yo (un novato) estoy probando mis conceptos sobre Scala''s Futures y los patrones correctos para usarlos.

La premisa
Los futuros de Scala son bloques de código que se ejecutarán de forma asíncrona. Por lo tanto, el hilo principal crea uno o más de esos futuros, se instala en éxito () [nota: igualmente aplicable a OnComplete / onFailure] devoluciones de llamada y ganancias. Las devoluciones de llamada se ejecutan cuando los futuros completan sus carreras.

Presumiblemente, estas devoluciones de llamadas generan resultados que se supone deben ser utilizados por el hilo principal. Los resultados se almacenan en un contenedor Try [T], con una restricción write-once / read-many. El principal (o cualquier otro hilo, pero ese no es el punto) decide cuándo alcanzar el máximo en el contenedor y recolectar los resultados para su posterior procesamiento.

Cualquiera que sea la discusión / blog / API a la que he puesto los ojos hasta ahora, menciona el hecho de que el hilo principal no tiene que esperar: puede seguir haciendo lo suyo, permitiendo que los futuros se ejecuten en paralelo y estén listos con el resultado.

Pregunta

Pero mi pregunta es: en el caso más simple, donde ha terminado de hacer lo que está haciendo, el hilo principal tendrá que esperar a que finalicen las devoluciones de llamada, ¿no es así? Y, como no se proporciona ningún mecanismo de interrupción que pueda indicar que el futuro ha finalizado la ejecución, el hilo principal no tiene otra opción que ''esperar'' (posiblemente con un límite de tiempo) para que el resultado esté listo. En otras palabras, en una aplicación, donde se emplean futuros, la espera es finalmente inevitable, ¿no es así?

Nota
Entiendo que podemos encadenar el futuro, usando combinators o Promise (y también hay otros patrones), para evitar este problema por completo. Pero, estoy tratando de aclarar mi concepto de que, en ciertos casos, usar futuros no evita la necesidad de esperar a que terminen.

¿Es una pregunta demasiado elemental? ¿Está mostrando un gran vacío en mi comprensión?

Answer 1

Sería útil comprender la diferencia teórica entre Await y async . Estos se conocen como bloqueo y no bloqueo, respectivamente.

Bloqueo

Un cálculo de bloqueo es muy parecido a un ciclo while.

while(!done) {
  if (isDone) {
    // do whatever
    done = true
  }
}

Esto es un cálculo de bloqueo sincrónico. El Thread no puede hacer nada más hasta que la acción de bloqueo se complete ya que está comprobando constantemente la acción.

Solo tiene tantos hilos como procesadores en la máquina. Con suerte, se puede ver cómo se pueden ocupar rápidamente y se forma una gran cola FIFO de "cosas que hacer".

Sin bloqueo

En esencia, el concepto es muy simple. En lugar de verificar continuamente si se hace algo, el control se realiza a intervalos de tiempo determinados. El Future se comprobará para completar cada 100 ms (digamos).

Lo asombroso es que durante cada uno de esos descansos de 100 ms, el hilo es libre de hacer otra cosa. Es por eso que obtienes un rendimiento superior de las cosas async .

Línea de fondo

Es físicamente posible que los procesadores hagan más cosas en un intervalo de tiempo dado. Es un silogismo muy simple.

Supongamos que usted y su amigo organizan una reunión para tomar un café a las 3 p.m. Él no aparece.

Puedes sentarte en la cafetería maldiciendo implacablemente o puedes ir a casa y hornear galletas. Mientras las galletas se hornean, revisa su teléfono cada 5 minutos hasta que finalmente envía mensajes de texto y luego se encuentra.

En el escenario 1, estás enojado y no has hecho mucho durante todo el día.

En el escenario 2, está encantado con su éxito culinario y está de muy buen humor para ver a un amigo.