Celluloid - Concorrência e relevância para um Ruby do futuro

Transcript

1. Celluloid "UPSFT
   DPODPSSÊODJB
   F
   SFMFWÃODJB
   QBSB
   P
   NVOEP
   3VCZ
2. @dodecaphonic Sou @dodecaphonic no Twitter. Fico com essa cara quando o computador não faz o que eu mando.
3. Š
   5PEP
   QPTU
   OP
   )BDLFS
   /FXT
   EFTEF
    "Ruby já era. Não tem como uma linguagem com x sobreviver em um mundo precisando de y."
4. VÁRIOS X E VÁRIOS Y X - tipos dinâmicos; Y - software complexo X - execução lenta; Y - software complexo/em escala X - metaprogramação em runtime; Y - software complexo X - ausência de concorrência; Y - software complexo
5. CONCORRÊNCIA NÃO É PARALELISMO Concorrência é a possibilidade de executar duas tarefas que se completarão em períodos que se sobrepõem. Isso não significa que as duas tarefas vão executar ao mesmo tempo — isso aí é paralelismo. Você pode ter concorrência até em máquinas single-threaded.
6. MAS EM RUBY TUDO É LINDO E FOFO! Não. Esta é uma área em que Ruby está bem defasado em relação a outras linguagens mais modernas/projetadas com isso em mente.
7. MRI E SUA TRAVA GLOBAL (GIL) Em Ruby a gente TEM concorrência — tem uma classe Thread, afinal. Mas é justamente aí onde a trava global do interpretador do Matz, a GIL, atrapalha a história de concorrência no Ruby. Você pode ter concorrência, mas não paralelismo (com a exceção do IO).
8. TER UMA TRAVA GLOBAL É BOM? Algumas pessoas (inclusive o ruby-core) consideram a GIL uma funcionalidade fofa dessas, que reduz certas classes de bugs clássicos de threading. Mas olha o custo: meu código roda, mas roda lento, não aproveita a máquina.
9. r:VLJIJSP
   .BUTVNPUP "I don't consider myself as the threading guy." E a solução para isso não vai vir da cabeça do Matz. Ele não se considera apto a resolver o problema. MINASWAN - MINCSWCN.
10. O que é que Threads oferecem, afinal? - Threads são contextos de execução que ficam subordinados a um processo do SO. Eles dividem o mesmo espaço de memória, ao contrário de processos; - Cada Thread pode, potencialmente, ser executado em paralelo pelo seu SO - A troca de contexto entre Threads é mais rápida do que em Processos
11. THREADS PROCESSOS vs Processos e Threads podem atingir os mesmos objetivos. Threads têm como vantagens consumir menos recursos e dividir o mesmo espaço de memória. Processos não exigem que você mude seu jeito de programar significativamente.
12. DESPERDÍCIO É FEIO Ou desperdiçaremos por não usarmos nenhum tipo de paralelismo, ou desperdiçaremos por usarmos processos e jogarmos fora memória, inserirmos latência na comunicação interna, etc.
13. Escreveu, não leu, e lá vem alguém dizer que programar com threads é difícil, até perigoso.
14. Mutex Monitor Condition Variable Thread-safe Race condition Deadlock No Ruby, como em outras linguagens, as preocupações são as mesmas. Os problemas principais são os mesmos.
15. # From: Working With Ruby Threads Order = Struct.new(:amount, :status) do def pending? status == 'pending' end ! def collect_payment puts "Collecting payment..." self.status = 'paid' end end ! order = Order.new(100.00, 'pending') ! 5.times.map do Thread.new do if order.pending? order.collect_payment end end end.each(&:join) Vamos usar um programinha que coleta pagamentos de pedidos.
16. $ ruby race.rb Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment...
17. $ ruby race.rb Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... WTF?
18. RACE CONDITION
19. 1 2 3 4 5 SO
20. 1 2 3 4 5 SO
21. 1 2 3 4 5 SO
22. 1 2 3 4 5 SO
23. 1 2 3 4 5 SO
24. 1 2 3 4 5 SO
25. 1 2 3 4 5 SO
26. 1 2 3 4 5 SO
27. 1 2 3 4 5 SO
28. 1 2 3 4 5 SO
29. MUTEXES Mutex - Mutual Exclusion, exclusão múltipla
30. shared_data = [] ! 10.times.map do Thread.new do 1000.times do shared_data << nil end end end.map(&:join) ! puts shared_data.size require "thread" ! shared_data = [] mutex = Mutex.new ! 10.times.map do Thread.new do 1000.times do mutex.synchronize { shared_data << nil } end end end.map(&:join) ! puts shared_data.size Sem Mutex Com Mutex
31. $ ruby array_append_no_mutex.rb 10000 $ chruby jruby $ ruby array_append_no_mutex.rb ConcurrencyError: Detected invalid array contents due to unsynchronized modifications with concurrent users << at org/jruby/RubyArray.java:1147 (root) at array_append_no_mutex.rb:6 times at org/jruby/RubyFixnum.java:275 (root) at array_append_no_mutex.rb:5 Sem Mutex O MRI dá a resposta que a gente espera, por conta da trava global do interpretador. A JVM nem deixa isso rodar, esse despautério.
32. $ ruby array_append_mutex.rb 10000 rubyonrio_mar14_celluloid/examples $ chruby jruby rubyonrio_mar14_celluloid/examples $ ruby array_append_mutex.rb 10000 Com Mutex Com o Mutex no lugar, tudo certo.
33. DEADLOCKS
34. 2 1 A B Threads Locks (Mutexes)
35. 2 1 A B Threads Locks (Mutexes)
36. 2 1 A B Threads Locks (Mutexes)
37. LIVELOCKS
38. A gente não vai ficar muito mais inteligente. O jeito é pensar em outras maneiras de resolver o problema.
39. Software Transactional Memory (Clojure) Communicating Sequential Processes (go, core.async do Clojure) Actors (Erlang, Akka, Celluloid) Três grandes ideias (não as únicas) e linguagens/bibliotecas em que elas estão proeminentemente implementadas.
40. ACTORS Mas primeiro, uma breve explicação do Actor Model.
41. 1973 Em 1973, Carl Hewitt et al bolaram uma visão computacional para um mundo em que computadores teriam dezenas, centenas, milhares de unidades de processamento independentes. Há 41 anos eles sabiam claramente daquilo que nós aqui no Ruby tentamos ignorar.
42. ERLANG Graças, em grande parte, ao Erlang, o modelo ficou bastante conhecido e as ideias geradas há quarenta anos passaram a povoar as mentes contemporâneas.
43. Mr. Red Actor 1973 Memory Ln. Boston, MA Um ator é uma entidade computacional que se comunica com outras por meio de mensagens. Cada ator é completamente independente do outro.
44. Mr. Red Actor 1973 Memory Ln. Boston, MA Eles só podem se comunicar usando o endereço da caixa de mensagens do ator. Não dá pra puxar o outro ator pelo braço e mandar ele fazer alguma coisa.
45. Mr. Red Actor 1973 Memory Ln. Boston, MA Da mesma maneira, o recipiente não sabe nada sobre quem mandou a mensagem: só interessa a mensagem em si. Esse desacoplamento entre as partes é uma ideia extremamente poderosa.
46. No modelo, as mensagens são enviadas de maneira assíncrona, em um esquema fire-and-forget. Não há garantia da ordem em que serão processadas.
47. Celluloid
48. r5POZ
    "SDJFSJ
    DSJBEPS
    EP
    $FMMVMPJE “… at the very least Celluloid puts threads on Rails. ! It makes it a lot easier to get right prototypes and get them done quickly and not spend a lot of time debugging all this stuff in the standard library.” Em uma entrevista com o rubista Jesse Storimer, o criador do Celluloid, Tony Arcieri, disse que gosta de pensar que o Celluloid é uma espécie de Threads on Rails.
49. ATORES QUE SÃO OBJETOS, OBJETOS QUE SÃO ATORES O Celluloid dá uma cara Ruby ao modelo de atores. Isso quer dizer que seu programa não vai ficar subitamente com outra cara, seguindo outros paradigmas, como quando se usa o EventMachine.
50. class ChocolateCake include Celluloid ! def lose_slice sleep 2 puts "Lost slice" end end Esta é a cara de um ator no Celluloid. A única coisa que precisa ser colocada é esse “include Celluloid”. A partir desse momento seu objeto é concorrente e está em seu próprio Thread.
51. BEIJINHO NO OMBRO PROS DEADLOCKS Celluloid uses a concurrent object model which combines method dispatch and thread synchronization. Each actor is a concurrent object running in its own thread, and every method invocation is wrapped in a fiber that can be suspended whenever it calls out to other actors, and resumed when the response is available. This means methods which are waiting for responses from other actors, external messages, or other system events (including I/O with Celluloid::IO) .
52. TOLERÂNCIA A FALHAS Inspirado pelo Erlang, o Celluloid segue a filosofia “let it crash”, permitindo que você estabeleça relações entre atores que determinem como o sistema deve se portar em caso de falhas.
53. TOLERÂNCIA A FALHAS Links O primeiro método é o link. Um ator se liga a outro, e seus destinos estão selados. (demo no pry)
54. TOLERÂNCIA A FALHAS Links Supervisores Inspirado pelo Erlang, o Celluloid segue a filosofia “let it crash”, permitindo que você estabeleça relações entre atores que determinem como o sistema deve se portar em caso de falhas.
55. COMPUTAÇÃO DISTRIBUÍDA (via DCell) A partir do momento que atores não estão ligados diretamente e só têm os endereços uns dos outros, um ator pode estar na mesma máquina ou não. O modelo de programação não muda.
56. IO ASSÍNCRONO COM ATORES (via Celluloid::IO) TOMA ESSA, NODE!
57. "MAS SÓ ME INTERESSA A WEB!"
58. A MORTE DO REQUEST—RESPONSE
59. BALLADINA
60. FIM
61. w IUUQHJUIVCDPNDFMMVMPJEDFMMVMPJE
    w IUUQHJUIVCDPNEPEFDBQIPOJDCBMMBEJOB
62. w IUUQXXXqJDLSDPNQIPUPT [JHB[PVJOQIPUPTUSFBN
    1FSJHP