Habiendo mónadas, ¿quién quiere callbacks?

Nunca me he visto en la tesitura de tener que usar callbacks porque no son mi guerra. Pero por lo que he oído de la gente que sabe mucho más que yo, son uno de esos infiernos de los que hay que huir con el mismo pavor que de los fors, los ifs, los elses (¡argggg! ¡he escrito else!) y los whiles.

Una pequeña maravilla teórica que me ha hecho replantearme la absoluta inutilidad de aquello que estudié en Álgebra III (funtores y demás) son las mónadas.

Y aunque

  • haya discusión sobre si los futuros son o no son mónadas y
  • en R no exista un flatmap propiamente dicho,

inspirado por todo lo anterior, el otro día escribí este pequeño bloque de código que, aun siendo mío, me maravilla:

library(magrittr)
library(future)

query.children <- function(x){
  future({
    tmp <- value(x)
    Sys.sleep(2)   # simulate waiting for resource
    tmp + 1
  })
}

query.node <- function(x){
  future({
    Sys.sleep(2)   # simulate waiting for resource
    x
  })
}

res <- query.node(1) %>% query.children %>% query.children

Ahora, en serio, ¿quién quiere callbacks?

5 comentarios sobre “Habiendo mónadas, ¿quién quiere callbacks?

  1. Iñaki 24 noviembre, 2016 13:47

    Efectivamente, los callbacks son otra guerra, y en los usos que hoy en día se le dan a R son dudosamente necesarios o deseables.

    Pero el código que ofreces sigue sin sustituirlos, dado que la última línea bloquea hasta que acaban todos los query.children y no puedo hacer nada más mientras tanto, que es la idea de un callback: asigno tarea y a mis cosas. ¯\_(ツ)_/¯

  2. Carlos J. Gil Bellosta 24 noviembre, 2016 13:50

    No bloquea. Si tienes suficientes workers (y puedes definir todos los que quieras, supongo que hasta 32k), no bloquea. Prueba.

  3. Iñaki 24 noviembre, 2016 15:33

    No bloquea con 4 cores y dos query.children. ¿Y si necesito 10 query.children (or whatever) encadenados? ¿Necesito 12 workers y 12 cores para que no bloquee? Que un código bloquee o no no puede depender del hardware y cuántos workers pongas (si se desea portabilidad, claro).

  4. Carlos J. Gil Bellosta 24 noviembre, 2016 18:17

    Puedes tener 300 workers con un solo core si quieres: se lanzan tantos procesos como sea necesario (con tope en 300) y el sistema operativo (¡estamos en 2016 y lo hace hasta Windows!) se encarga del resto. El otro día hice una prueba con cientos de workers (pero 4 núcleos) para scrapear un portal con pésima praxis y mínima cordialidad para con el Apache víctima e iba como un tiro.

  5. Iñaki 24 noviembre, 2016 19:45

    Pero el hecho es que el ejemplo del post puede bloquear porque lo he probado en una máquina con 2 cores y te aseguro que está bloqueando, pongas los workers que pongas.

Los comentarios están desabilitados.