Las fibras son algo que probablemente nunca usará directamente en el código de nivel de aplicación. Son una primitiva de control de flujo que puede usar para construir otras abstracciones, que luego usa en código de nivel superior.
Probablemente el uso # 1 de fibras en Ruby es implementar Enumerator
s, que son una clase central de Ruby en Ruby 1.9. Son increíblemente útiles.
En Ruby 1.9, si llama a casi cualquier método iterador en las clases principales, sin pasar un bloque, devolverá un Enumerator
.
irb(main):001:0> [1,2,3].reverse_each
=> #<Enumerator: [1, 2, 3]:reverse_each>
irb(main):002:0> "abc".chars
=> #<Enumerator: "abc":chars>
irb(main):003:0> 1.upto(10)
=> #<Enumerator: 1:upto(10)>
Estos Enumerator
s son objetos Enumerables, y sus each
métodos producen los elementos que habrían sido generados por el método iterador original, si se hubiera llamado con un bloque. En el ejemplo que acabo de dar, el Enumerador devuelto por reverse_each
tiene un each
método que produce 3,2,1. El enumerador devuelto por chars
produce "c", "b", "a" (y así sucesivamente). PERO, a diferencia del método iterador original, el Enumerador también puede devolver los elementos uno por uno si llamanext
repetidamente:
irb(main):001:0> e = "abc".chars
=> #<Enumerator: "abc":chars>
irb(main):002:0> e.next
=> "a"
irb(main):003:0> e.next
=> "b"
irb(main):004:0> e.next
=> "c"
Es posible que haya oído hablar de los "iteradores internos" y los "iteradores externos" (en el libro Patrones de diseño "Gang of Four" se ofrece una buena descripción de ambos). El ejemplo anterior muestra que los enumeradores se pueden usar para convertir un iterador interno en uno externo.
Esta es una forma de crear sus propios enumeradores:
class SomeClass
def an_iterator
# note the 'return enum_for...' pattern; it's very useful
# enum_for is an Object method
# so even for iterators which don't return an Enumerator when called
# with no block, you can easily get one by calling 'enum_for'
return enum_for(:an_iterator) if not block_given?
yield 1
yield 2
yield 3
end
end
Vamos a intentarlo:
e = SomeClass.new.an_iterator
e.next # => 1
e.next # => 2
e.next # => 3
Espera un minuto ... ¿Hay algo extraño ahí? Escribió las yield
declaraciones an_iterator
como código de línea recta, pero el enumerador puede ejecutarlas una a la vez . Entre llamadas a next
, la ejecución de an_iterator
se "congela". Cada vez que llama next
, continúa funcionando hasta el siguienteyield
declaración y luego se "congela" nuevamente.
¿Puedes adivinar cómo se implementa esto? El enumerador envuelve la llamada an_iterator
en una fibra y pasa un bloque que suspende la fibra . Entonces, cada vez que an_iterator
cede el paso al bloque, la fibra en la que se está ejecutando se suspende y la ejecución continúa en el hilo principal. La próxima vez que llame next
, pasa el control a la fibra, el bloque regresa yan_iterator
continúa donde lo dejó.
Sería instructivo pensar en lo que se necesitaría para hacer esto sin fibras. CADA clase que quisiera proporcionar iteradores internos y externos tendría que contener código explícito para realizar un seguimiento del estado entre llamadas a next
. Cada llamada a next tendría que verificar ese estado y actualizarlo antes de devolver un valor. Con las fibras, podemos convertir automáticamente cualquier iterador interno en uno externo.
Esto no tiene que ver con las fibras persay, pero déjame mencionar una cosa más que puedes hacer con los enumeradores: te permiten aplicar métodos Enumerables de orden superior a otros iteradores distintos de each
. Piense en esto: normalmente todos los métodos enumerables, incluyendo map
, select
, include?
, inject
, y así sucesivamente, todos los trabajos en los elementos producidos por each
. Pero, ¿y si un objeto tiene otros iteradores además deeach
?
irb(main):001:0> "Hello".chars.select { |c| c =~ /[A-Z]/ }
=> ["H"]
irb(main):002:0> "Hello".bytes.sort
=> [72, 101, 108, 108, 111]
Llamar al iterador sin bloque devuelve un Enumerador, y luego puede llamar a otros métodos Enumerables sobre eso.
Volviendo a las fibras, ¿ha utilizado el take
método de Enumerable?
class InfiniteSeries
include Enumerable
def each
i = 0
loop { yield(i += 1) }
end
end
Si algo llama a ese each
método, parece que nunca debería regresar, ¿verdad? Mira esto:
InfiniteSeries.new.take(10) # => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
No sé si esto usa fibras debajo del capó, pero podría. Las fibras se pueden utilizar para implementar listas infinitas y evaluación perezosa de una serie. Para ver un ejemplo de algunos métodos perezosos definidos con enumeradores, he definido algunos aquí: https://github.com/alexdowad/showcase/blob/master/ruby-core/collections.rb
También puede construir una instalación de corrutina de uso general utilizando fibras. Nunca he usado corrutinas en ninguno de mis programas, pero es un buen concepto para conocer.
Espero que esto les dé una idea de las posibilidades. Como dije al principio, las fibras son una primitiva de control de flujo de bajo nivel. Hacen posible mantener múltiples "posiciones" de flujo de control dentro de su programa (como diferentes "marcadores" en las páginas de un libro) y cambiar entre ellos como desee. Dado que el código arbitrario puede ejecutarse en una fibra, puede llamar a código de terceros en una fibra y luego "congelarlo" y continuar haciendo otra cosa cuando vuelva a llamar al código que controla.
Imagínese algo como esto: está escribiendo un programa de servidor que dará servicio a muchos clientes. Una interacción completa con un cliente implica seguir una serie de pasos, pero cada conexión es transitoria y debe recordar el estado de cada cliente entre las conexiones. (¿Suena como programación web?)
En lugar de almacenar explícitamente ese estado y verificarlo cada vez que un cliente se conecta (para ver cuál es el siguiente "paso" que tienen que hacer), podría mantener una fibra para cada cliente. Después de identificar al cliente, recuperaría su fibra y la reiniciaría. Luego, al final de cada conexión, suspendería la fibra y la almacenaría nuevamente. De esta manera, podría escribir código de línea recta para implementar toda la lógica para una interacción completa, incluidos todos los pasos (tal como lo haría naturalmente si su programa se ejecutara localmente).
Estoy seguro de que hay muchas razones por las que tal cosa puede no ser práctica (al menos por ahora), pero nuevamente estoy tratando de mostrarles algunas de las posibilidades. Quién sabe; Una vez que obtenga el concepto, ¡puede que se le ocurra una aplicación totalmente nueva en la que nadie más ha pensado todavía!