Edgard Lemos wrote:
>
> Em ter, 10 jul 2001, Lisias Toledo escreveu:
> > Edgard Lemos wrote:
[...]
> > S�o duas ferramentas de programa��o diferentes, cada uma com sua aplica��o.
>
> Quais s�o as aplica��es para cada tipo de ferramenta, e por que o
> artigo disse que o Linux trata processo e thread do mesmo jeito?
Eu n�o conhe�o a arquitetura do Linux neste n�vel, mas posso *inferir* que as
chamadas de cria��o de threads, em algum lugar do kernel, viram chamadas de
cria��o de processos.
Agora vamos para um exemplo do uso de ambos:
Vc tem um servidor daemon que fica monitorando uma porta � espera de clientes.
Quando um chega, o daemon chama uma c�pia dele mesmo para responder, e avisa
ao cliente para se conectar com o daemon filho em outra porta.
Existem duas abordagens para vc resolver este problema digno do personagem
Spawn (que por sinal, � um dos nomes que se d� � esta t�cnica - spawning), que
� criar demoniozinhos... 8-P
Vamos supor que estes pedidos ocorram dezenas de vezes por segundo, e s�o
usados apenas para pedir a hora certa. N�o existe perigo nenhum em dizer que
horas s�o, as respostas leva apenas poucos milisegundos (e provavelmente s�o
por UDP, para evitar perder tempo com conex�oes TCP) e n�o existe muitos
riscos de que um cliente interfira no outro. Usar processo aqui � desperd�cio,
n�o existem dados privados para cada cliente, o servi�o � servido de forma
instant�nea e ef�mera. E se o daemon travar, o preju�zo ser� pouco. Ent�o vc
usa uma thread.
Mas por outro lado, vamos supor que o servi�o � fornecer uma interface WEB
para as contas banc�rias do cidad�o. Existem muitos dados sensitivos nesta
situa��o, vc definitivamente n�o quer que a thread do cliente A possa acessar
os dados do cliente B, mesmo que o daemon tenha sido escrito por vc (afinal,
vai que algum FDP inteligente passe a perna na seguran�a que vc imaginava
inviol�vel). J� imaginou? Apenas uma invas�o e todos os clientes on-line est�o
comprometidos... Al�m disso, se algum servi�o enlouquecer e ferrar com a
mem�ria do programa, TODAS as conex��es caem, porque a mem�ria �
compartilhada. Ent�o, aqui � melhor usar processos. Ao menos, se algu�m
enlouquecer, morre sozinho.
--
[]s,
([EMAIL PROTECTED])
Quote of week: The day Micro$oft makes something that doesn't suck is the day
they start selling vacuum cleaners.
Assinantes em 11/07/2001: 2260
Mensagens recebidas desde 07/01/1999: 122415
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
