Кроссплатформенный https сервер с неблокирующими сокетами

В реальных задачах используется хотя бы select, не говоря уже о более продвинутых способах.

Активное ожидание, пусть и с вызовом sleep — суть костыль.

Сколько соединений сможет одновременно «держать» ваш сервер? Я не вижу полного кода, поэтому тут либо 1, либо 1000. Это и есть проблема.

Обычный многопоточный сервер, работающий на блокирующих сокетах, держит 1000 соединений. Потом заканчиваются ресурсы операционной системы — и она не дает создавать больше потоков. Или все начинает тормозить и лагать.

Неблокирующие сокеты — это способ повысить лимит числа соединений дальше. Классическая схема с select поддерживает до 10 000 соединений, дальше начинаются проблемы в силу квадратичной природы алгоритма. Однако, и большее число соединений держится, пусть и с лагами.

Дальше идут такие вещи, как poll, epoll, /dev/poll, kevent, асинхронные сокеты и куча других страшных слов, с которыми лично я никогда не работал. Там можно обрабатывать одновременно столько соединений, сколько способен держать сетевой стек ОС — своих накладных расходов эти способы накладывают крайне мало.

Тут и я не нужен, достаточно на код автора посмотреть, он хоть очень странный, написан просто ужасно, да и выедает процессор в бесконечном цикле так, что лучше бы уж блокировался, но тем не менее, из него видно, что SSL_do_handshake/SSL_read/SSL_write возвращают управление в функцию, сигнализируя SSL_ERROR_WANT_READ и SSL_ERROR_WANT_WRITE, после чего остается только взвести таймер и положить дескриптор на соответствующее событие в epoll/kqueue/eventports/по_вкусу.

If the underlying BIO is non-blocking, SSL_do_handshake() will also return when the underlying BIO could not satisfy the needs of SSL_do_handshake() to continue the handshake. In this case a call to SSL_get_error() with the return value of SSL_do_handshake() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_do_handshake(). The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition. When using a buffering BIO, like a BIO pair, data must be written into or retrieved out of the BIO before being able to continue.

www.openssl.org/docs/ssl/SSL_do_handshake.html

Тип SOCKET, в винде беззнаковый, а в никсах сокеты имеют знаковый тип int, а у Вас все присваивается типу int.

Уже ответили что в винде не -1. Товарищи, разрабатывающие pvs studio пишут про эту ошибку чуть ли не в каждой статье.
К тому же в MSDN вполне чёрным по белом что ошибка функции accept это именно INVALID_SOCKET, а не что-то другое. И именно на него надо проверять если нет желания когда-то потом мучаться с совместимостью и переносимостью кода.
Стоило хотя бы упомянуть что код ошибки стоит проверять что это действительно всё ок для неблокирующего вызова. Это всего пара лишних макросов чтобы свести к единому виду, можно даже было бы привести в статье.

Вы же сами ответили:

Я в примерах вижу в цикле вызывает accept без каких либо других действий внутри цикла. А обработка коннекта идёт после выхода из него.
Чем это отличается блокирующего вызова кроме ухудшения производительности из-за слипа?
Должно быть примерно так всё же:

while(1) {
  accept
  ...
  // делаем что-то там нам нужное со старыми открытыми коннектами или с новым
}
...
// закрваем сокеты