MICO e' "reentrant"?

[Nelson Posse Lago <PROTECTED>]

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