In den Manpages für nicht blockierende Sockets sind zwei Fälle gut dokumentiert:

Wenn send () dieselbe Länge wie der Übertragungspuffer zurückgibt,die gesamte Übertragung erfolgreich beendet, und der Socket befindet sich möglicherweise in einem Zustand, in dem EAGAIN / EWOULDBLOCK den nächsten Aufruf mit> 0 zu übertragenden Bytes zurückgibt.Wenn send () -1 zurückgibt und errno EAGAIN / EWOULDBLOCK ist,keine der übertragung beendet, und das Programm muss warten, bis der Socket für weitere Daten bereit ist (EPOLLOUT im Fall epoll).

Was für nicht blockierende Sockets nicht dokumentiert ist:

Wenn send () einen positiven Wert zurückgibt, der kleiner als die Puffergröße ist.

Ist es sicher anzunehmen, dass send () EAGAIN / EWOULDBLOCK auch für ein weiteres Datenbyte zurückgibt? Oder sollte ein nicht blockierendes Programm versuchen, noch einmal () zu senden, um einen schlüssigen EAGAIN / EWOULDBLOCK zu erhalten? Ich mache mir Sorgen, ob ich einen EPOLLOUT-Watcher in den Socket stecken soll, wenn er nicht tatsächlich blockiert ist, um darauf zu reagieren, dass er aus dem Socket kommt.

Offensichtlich hat die letztere Strategie (erneut versucht, etwas Bestimmtes zu erreichen) ein genau definiertes Verhalten, ist jedoch ausführlicher und beeinträchtigt die Leistung.