isacmarques escreveu:
Tudo funciona direitinho quando esta dentro da main() mas quando chamo ela em uma thread os dados são lidos no entanto quando ocorre o problema listado no link acima a mesma trava ou seja o tratamento que eu fiz só funciona dentro da main na thread ele trava, parecendo que eu não tratei falhas de comunicação nesta função.
Desde já agradeço a ajuda de vocês mais uma vez.
Você está usando threads diferentes para ler coisas diferentes ao mesmo tempo?
A abordagem que eu mostrei depende de sinais, que são entes vinculados
a processos, não a threads. Se você tem uma thread que define um alarme e outra que supostamente define ou desliga outro alarme, o que fora definido pela primeira thread é sobrescrito pelo da segunda, pois o processo só pode ter um alarme de cada vez. Além disso, se chega o sinal de alarme ao processo, ele pode ser despachado para qualquer uma das threads, sem que você tenha muita escolha sobre qual thread será interrompida por ele para tratá-lo.
Quando se programa com threads, o buraco sempre é um pouco mais em baixo.
O que você pode fazer? Depende das suas necessidades. Eu pensei em algumas opções, listadas abaixo em ordem aproximadamente crescente de dificuldade, que podem ou não satisfazer suas necessidades.
Opção 1: usar diferentes processos, em lugar de diferentes threads (nesse caso, os dados de um processo não serão compartilhados com os demais, a não ser que você manualmente use algum mecanismo de memória compartilhada ou
memory mapped I/O).
Opção 2: usar um processo só e com uma thread só, descritores de arquivos com o flag
O_NONBLOCK ligado (ver
open() e
fcntl()), e usar
select(),
poll() ou
epoll() para identificar quais descritores tiveram atividades dentro do timeout especificado (nesse caso, a execução do processo pode ficar temporariamente suspensa durante o tempo de timeout).
Opção 3: adaptar a opção acima para trabalhar sempre com timeouts nulos na hora de invocar
select(),
poll() ou
epoll(), de modo a paralisar o processo pelo menor tempo possível para esperar por eventos de E/S (se você quiser ter um timeout de cada canal de comunicação, terá de fazer essa contagem por conta própria).
Opção 4: adaptar a opção 2 para trabalhar com exatamente duas threads, sendo uma para cuidar de E/S, e outra para controlar tudo o que não depende de E/S (você tem de ter muito cuidado para sincronizar o acesso a dados que sejam comuns entre as duas threads; leia sobre
mutexes).
Opção 5: trabalhar com uma thread para cada descritor onde ocorram operações de E/S, e
select(),
poll() ou
epoll() em cada thread exclusivamente para testar o descritor associado a essa thread (note que o problema de sincronização de acesso a dados comuns pode ficar mais complexo na medida em que o número de threads aumenta).
