O valor de retorno “-1” do método de soquete de função close () é possível?

Question

Em que circunstâncias é possível produzir um valor de retorno de -1 ao fechar um soquete de rede usando o método close (int fildesc)? Suponho que seja possível com um número fildesc inválido, mas isso pode acontecer com um soquete válido e existente?

Como um programa deve reagir caso isso aconteça?

    

Answer 1

A página de manual do Linux descreve algumas situações possíveis em que close() retorna -1 em descritores de arquivos válidos:

Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

Suponho que essa parte se aplicaria a outros kernels que ao Linux. Então é seguido por esta advertência (enfatizada por mim):

Note that the return value should be used only for diagnostics. In particular close() should not be retried after an EINTR since this may cause a reused descriptor from another thread to be closed.

Você pode querer ler algumas razões para isso em este artigo do lwn.net :

The file descriptor passed to close() is de-allocated early in the processing of the system call and the same descriptor could already have been handed out to another thread by the time close() returns.

Assim, para descritores de soquete, podemos encontrar EINTR ao fechar um soquete especialmente depois de enviar um volume de dados com ele, no entanto, devemos nunca escrever código como este no Linux:

while (close(sock) == -1 && errno == EINTR);