Dwa przypadki są dobrze udokumentowane na stronach podręcznika dla gniazd nieblokujących:

Jeśli send () zwraca tę samą długość co bufor przesyłania,cały transfer zakończone pomyślnie, a gniazdo może być w stanie zwrócenia EAGAIN / EWOULDBLOCK następnego połączenia z> 0 bajtów do przesłania.Jeśli send () zwraca -1, a errno to EAGAIN / EWOULDBLOCK,żaden z transferu zakończony, a program musi czekać, aż gniazdo będzie gotowe na więcej danych (EPOLLOUT w przypadku epolla).

Co nie jest udokumentowane dla gniazd nieblokujących to:

Jeśli send () zwraca wartość dodatnią mniejszą niż rozmiar bufora.

Czy można bezpiecznie założyć, że send () zwróci EAGAIN / EWOULDBLOCK na jeszcze jednym bajcie danych? Czy może program nieblokujący powinien spróbować wysłać () jeszcze raz, aby uzyskać rozstrzygający EAGAIN / EWOULDBLOCK? Martwię się o umieszczenie obserwatora EPOLLOUT na gnieździe, jeśli tak naprawdę nie jest w stanie „zablokować”, aby odpowiedzieć na to wyjście.

Oczywiście ta druga strategia (próbując ponownie uzyskać coś rozstrzygającego) ma dobrze zdefiniowane zachowanie, ale jest bardziej gadatliwa i stawia hit na wydajności.