RES: MICO e' "reentrant"?

["Roberto Pires de Carvalho" <PROTECTED>]

hum, talvez ter uma thread para cada envio de mensagem seja muito overhead pro servidor, e acabaria gastando tanto tempo quanto o envio serial se houver uma quantidade razoável de salas e usuários. Acho que uma forma mais bonita seria implementar uma fila de mensagens. Numa ponta as mensagens enviadas pelos usuários são adicionadas à fila, e na outra ponta uma quantidade limitada de threads ficam verificando se existem mensagens a serem enviadas para os usuários. Assim não se tem mais o overhead de se criar e destruir threads a toda hora, e se houverem muitos usuários o servidor poderia criar algumas threads a mais para ajudar no envio de mensagens. Quando o número de usuários cair então o servidor poderia reduzir as threads ativas que estão sem fazer nada.
 
Seria um esquema produtor-consumidor, com vários produtores e vários consumidores. Acho que esse esquema só funcionaria no caso do push (já que no pull o servidor não precisa enviar as mensagens), e mesmo assim seria algo muito complicado pra se fazer num EP que tem que entregar semana que vem.
 
T+
 
 
-----Mensagem original----- 
De: Nelson Posse Lago [mailto:PROTECTED] 
Enviada: ter 26-mar-02 18:44 
Para: PROTECTED 
Cc: 
Assunto: MICO e' "reentrant"?



	Ois,
	
	Respondendo `a minha questao anterior (o que acontece com multiplas
	invocacoes simultaneas), o MICO permite que o POA seja inicializado de
	modo a "serializar" as requisicoes ou de modo a criar "threads" para cada
	requisicao; no entanto, esse segundo comportamento nao e' implementado e,
	portanto, no MICO as requisicoes sao sempre executadas sequencialmente.
	
	Ai' dei uma olhada no FAQ e na documentacao do MICO e nao descobri: eu vou
	ter algum problema fazendo um programa com multiplos "threads" que usa o
	MICO?  Ou seja, as chamadas de funcao que "passam" pelo MICO sao
	"thread-safe"? E sao "reentrant"?
	
	O meu problema e': para implementar o sistema baseado em "push", o
	servidor tem que fazer um monte de requisicoes remotas atraves do CORBA;
	mas se um cliente tiver sido desconectado, ou tiver uma conexao muito
	lenta, fazer todas as requisicoes sequencialmente sera' muito lento (na
	verdade, sera' lento tambem se houver um numero razoavelmente grande de
	pessoas numa "sala"): e' muito melhor fazer varias requisicoes
	simultaneamente. Mas como essas requisicoes bloqueiam o servidor, e'
	preciso gerar um "thread" no servidor para cada cliente, e vamos ter
	varias chamadas corba rodando simultaneamente. Dependendo de como o MICO
	e' implementado, se o codigo do MICO nao for reentrante, isso nao vai
	funcionar. Na verdade, mesmo essa solucao nao e' a melhor (um thread para
	cada cliente nao parece muito bom :-), mas imagino que a solucao "ideal"
	deve ser um tanto quanto "cabeluda"; o livro do Vinoski fala em chamadas
	"deferred", mas parece que nao da' pra usar sempre...
	
	O pior e' que a coisa melhora um pouco, mas nao muito, no caso do pull:
	como o MICO nao e' multithreaded, se um cliente faz uma requisicao e a
	rede faz com que a resposta do servidor demore a ser recebida, as outras
	requisicoes vao ficar "paralisadas", esperando o servidor terminar a
	requisicao anterior.
	
	Ate' +
	Nelson