Unix Process
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Unix Process

on

  • 357 views

Tech Talk realizado na Dito Internet sobre processos unix. O objetivo foi mostrar um pouco mais desse universo para o pessoal de TI.

Tech Talk realizado na Dito Internet sobre processos unix. O objetivo foi mostrar um pouco mais desse universo para o pessoal de TI.

Statistics

Views

Total Views
357
Views on SlideShare
312
Embed Views
45

Actions

Likes
0
Downloads
7
Comments
0

4 Embeds 45

http://localhost 38
http://www.sergiohenriquemiranda.com.br 4
http://104.131.107.175 2
http://sergiohenriquemiranda.com.br 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Unix Process Presentation Transcript

  • 1. Unix Process
  • 2. Todos vocês já usaram...
  • 3. Tudo isso estásendo executadoatravés de umPROCESSO
  • 4. Um pouco de história- A programação unix existe desde 1970- Foi inventado nos laboratórios Bell (Bell labs)- Os conceitos e técnicas de programação unixnão são novidades. Essas técnicas vão além daslinguagens de programação.- Essas técnicas não são modificadas há décadas
  • 5. Processos- Quem sabe a diferença entre userland e kernel?
  • 6. ProcessosKernel- É a camada que está em cima do hardware. Ouseja, é o homem do meio entre toda interação queacontece entre a userland e o hardware- Essas interações incluem coisas como:. Ler/Escrever no diretório de arquivos. Enviar arquivos pela rede. Alocar memória. Tocar música através dos auto-falantesDevido ao seu poder, nenhum programa possuiacesso direto ao Kernel
  • 7. ProcessosUserland- É onde todos os seus programas são executados- Seu programa pode fazer muita coisa semprecisar do kernel:. Realizar operações matemáticas. Realizar operações com strings. Controle de fluxo através de operações lógicasMas se você quiser fazer várias coisas legais teráque utilizar o kernel
  • 8. ProcessosSystem call- Qualquer comunicação entre o kernel e userlandé feita através de system calls- É a interface que conecta o kernel e a userland- Define as interações que são permitidas entre oseu programa e o hardware
  • 9. ProcessosProcess identifier (pid)- Todo processo possui um identificador único- Nada mais é que um número sequencial. É assimque o kernel vê o seu processo: como um número>> puts Process.pid || $$ #system call: getpid- Não está ligado a nenhum aspecto do conteúdodo processo.- Pode ser entendido por qualquer linguagem deprogramação
  • 10. ProcessosParents process (ppid)- Todo processo rodando no seu sistema possuium pai- O processo pai é o processo que invocou outrodeterminado processo.>> puts Process.ppid #system call: getppid- O ppid pode ser importante quando estivermosdetectando processos deamons
  • 11. ProcessosFile descriptors- Representa arquivos abertos- Em unix tudo é arquivo!. Isso significa que dispositivos são tratados comoarquivo, sockets e pipes são tratados comoarquivos e arquivos são tratados como arquivos!- Qualquer momento que você abrir um recurso, éatribuido um número de file descriptor a esserecurso
  • 12. ProcessosFile descriptors- Não são compartilhados entre processos que nãoestão relacionados- Eles vivem e morrem com o processo que elesestão ligados>> file = File.open(“path/to/the/file”)>> file.fileno=> 3- É através do fileno que o kernel consegue mantero controle dos recursos que seu processo estáutilizando
  • 13. ProcessosFile descriptors- Apenas recursos abertos possuem filedescriptors- Todo processo unix vem com três recursosabertos. STDIN. STDOUT. STDERR- Existe uma limitação de 1024 file descriptorsabertos por processo
  • 14. ProcessosEnvironment variables- São pares chave-valor que possuem dados paraos processos- Todo processo herda variáveis de ambiente deseus pais- São definidas por processo e são globais paracada processo$ MESS=‘teste’ ruby -e “puts ENV[‘MESS’]”
  • 15. ProcessosArgumentos- ARGV: argument vector- É uma forma de passar argumentos para osprocessosp ARGV$ ruby argv.rb foo bar -ba[“foo”, “bar”, “-ba”]
  • 16. ProcessosPossuem nome- Todo processo possue um nome e esse nomepode ser mudado durante seu runtime>> puts $PROGRAM_NAME- É uma forma eficiente de comunicar a tarefa queestá sendo desenvolvida=> irb
  • 17. ProcessosPossuem um código de finalização- Todo processo, ao finalizar, possui um código- É um número entre 0-255 que denota se oprocesso finalizou com sucesso ou não- A finalização com um código 0 indica que tudoocorreu como esperado- Mas... Os outros códigos são utilizados comoforma de comunicação
  • 18. ProccessCAN use theFORK
  • 19. ProcessosFork- É um dos conceitos mais poderosos daprogramação unix- Permite que um processo em execução crie outroprocesso, utilizando recursos de programaçãopara isso- O novo processo criado é uma cópia exata doprocesso original
  • 20. ProcessosFork- O processo filho herda uma cópia de todamemória usada pelo processo pai bem como todosos file descriptorsRecapitulando...- O ppid do processo filho é o pid do processo pai.- O processo filho possui o mesmo mapa de filedescriptors que o processo pai
  • 21. ProcessosForkif forkputs “entrando no if”elseputs “entrando no else”end=> entrando no if=> entrando no elseWTF???- O método fork retorna duas vezes (ele cria outroprocesso, lembra??)- Retorna uma vez no processo pai e uma vez noprocesso filho
  • 22. ProcessosForkputs “processo pai #{Process.pid}”if forkputs “entrando no if atraves do processo #{Process.pid}”elseputs “entrando no else atraves do processo #{Process.pid}”end=> processo pai 2000=> entrando no if atraves do processo 2000=> entrando no else atraves do processo 2010- O processo filho é finalizado após executar ocódigo que está no else- O retorno do fork no processo pai é o pid do filho.Já no processo filho o fork retorna nil
  • 23. ProcessosForkMulticore Programming- Não é garantido de ser distribuido através dasCPUs disponíveis. Depende do SO- É preciso ser feito com cuidado!# system call => fork
  • 24. ProcessosProcessos orfãosfork do5.times dosleep 1puts “Eu sou orfão!”endendabort “Parent process died ...”- O que acontece com um processo filho quandoseu pai morre?. Nada!
  • 25. ProcessosCoW Friendly- Copiar toda memória na hora do fork pode serconsiderado um overhead- Sistemas Unix modernos empregam uma técnicachamada Copy on Write para evitar o overhead- A cópia da memória é evitada até que algumaescrita seja necessária- Dessa forma o processo pai e o processo filhocompartilham a memória até uma escrita serrealizada pelo processo filho
  • 26. ProcessosCoW Friendlyarr = [1,2,4]fork do# nesse momento não há copia de memória# a leitura é feita de forma compartilhadaputs arrendfork do# Ao modificar o array uma cópia do array precisa ser feita# para o processo filhoarr << 4end- Isso mostra que realizar um fork é rápido- Os processos filhos possuem uma cópia dosdados modificados. O resto pode sercompartilhado
  • 27. ProcessosCoW Friendly- MRI não é CoW friendly. O garbage collector utiliza um algoritmo ‘mark-and-sweep’ que não é compatível com cow. O algoritmo realiza uma iteração por todo objetoexistente marcando se o mesmo deve ser coletadoou não. Dessa forma, quando o garbage collector rodartoda memória sera copiada para o processo filho
  • 28. ProcessosPodem esperar- Realizar um fork e não esperar o resultado éinteressante para tarefas assincronasmessage = “Opa, bão?”recipient = “rodrigo.diley@dito.com.br”fork doStatsCollector.record message, recipientend#continua o envio da mensagem- Mas em alguns outros casos você quer manter ocontrole sobre seus processos filhos
  • 29. ProcessosPodem esperarfork do5.times dosleep 1puts “Eu sou orfão!”endend- Basta utilizar em ruby: Process.waitProcess.waitabort “Processo pai morreu ...”=> “Eu sou orfão!”=> “Eu sou orfão!”=> “Eu sou orfão!”=> “Eu sou orfão!”=> “Eu sou orfão!”=> “Processo pai morreu ...”
  • 30. Podem esperar- Process.waitProcessos. É uma chamada bloqueante que faz o processopai esperar por um de seus filhos terminar aexecução. É você que precisa saber qual processo estásendo terminado. Process.wait retorna o pid doprocesso filho
  • 31. ProcessosPodem esperar- Condições de corrida. O que acontece quando um processo pai demorapara realizar a chamada ao metodo wait?. O Kernel coloca todas as informações de exit dosprocessos filhos em uma fila!. Se Process.wait for chamado e não existirprocesso filho será lançada uma exception
  • 32. ProcessosZombieee- É sempre bom limpar os processos filhos- O Kernel guarda informações de todos osprocessos filhos em um fila, estão lembrados?- Se nós não retirarmos ela de lá, quem irá?NINGUEM- Estamos gastando mal os recursos do Kernel
  • 33. ProcessosZombieeemessage = “Opa, bão?”recipient = “rodrigo.diley@dito.com.br”pid = fork doStatsCollector.record message, recipientendProcess.detach(pid)#continua o envio da mensagem- Arrumando nosso exemplo- Basicamente, Process.detach dispara uma novathread que terá como terefa esperar o processofilho terminar
  • 34. ProcessosZombieee- Todo processo filho que termina e não possuiseus status coletado é considerado zombiepid = fork { sleep(1) }puts pidsleep$ ps -ho pid,state -p [pid do processo]- O status impresso será z ou Z+
  • 35. ProcessosRecebem sinais- Process.wait é uma chamada bloqueante- Como esperar por processos filhos em processospais que estão sempre ocupados?. Basta trabalhar com sinais!. CHLD é o sinal que o kernel envia para oprocesso pai indicando que um processo filho foifinalizado
  • 36. ProcessosRecebem sinaischild_process = 3dead_process = 0child_process.times dofork dosleep 3endendtrap(:CHLD) dowhile pid = Process.wait(-1, Process::WNOHANG)puts piddead_process += 1exit if dead_process == child_processendendloop do(Math.sqrt(rand(44)) ** 8).floorsleep 1end
  • 37. ProcessosRecebem sinais- É uma forma de comunicação assincrona- Quando um processo recebe um sinal do Kernelas seguintes ações podem ser tomadas:. Ignorar. Realizar algum comportamento específico. Realizar o comportamento padrão
  • 38. ProcessosRecebem sinais- Os sinais são enviados através do Kernel- Basicamente, o Kernel é o middleman utilizadopelos processos para enviarem sinais uns aosoutros
  • 39. ComputadorLIGADO rodandotask remotaNUNCA MAIS
  • 40. ProcessosRecebem sinais- Se sua tarefa já estiver rodando em um consolebasta enviar o sinal de stop para que a tarefa sejainterrompida- Após sua interrupção basta colocá-la para rodarem background através do comando bg- Basta remover o vínculo com o terminal atravésdo comando disown
  • 41. ProcessosPodem se comunicar- Existem algumas formas de realizar IPC (Inter-process communication). Pipe. Sockets
  • 42. ProcessosPodem se comunicar- Pipe. É um caminho de mão única de fluxo de dadosreader, writer = IO.pipe => [#<IO:fd 5>, #<IO:fd 6>]writer.write(“Galo doido não perde em casa”)writer.closeputs reader.read=> “Galo doido não perde em casa”. É um stream de dados!
  • 43. ProcessosPodem se comunicar- Pipe. É um recurso compartilhado como qualqueroutroreader, writer = IO.pipe => [#<IO:fd 5>, #<IO:fd 6>]fork doreader.close10.times do#trabalhando...writer.puts “Quase acabando”endendwriter.closewhile message = reader.gets$stdout.puts messageend
  • 44. ProcessosPodem se comunicar- Sockets. Pode ser um socket unix, para comunicaçãolocal. Pode ser um socket tcp, para comunicaçãoremota- Outra possível solução seria RPC
  • 45. ProcessosDeamon- São processos que rodam em background e quenão estão ligados a nenhum terminal controladopelo usuário- Tem um processo deamon que é muitoimportante para o sistema operacional. É o pai de todos. É o processo chamado init, seuppid é 0 e o seu pid é 1
  • 46. ProcessosDeamon- Process group e session group$ git log | grep shipped | less- Todo sinal enviado para o pai de um processgroup é encaminhado para os filhos- Todo sinal encaminhado para um session groupé encaminhado para os processos que fazem partedesse grupo
  • 47. OBRIGADO!@sergiohenriquesergio.miranda@dito.com.br