История изменений

Если уже добавлять poll перед read, тогда сразу и сокет делать блокирующем.

Не надо советовать человеку плохое. «Сработавший» POLLOUT не гарантирует то, что операция записи на блокирующем дескрипторе не заблокирует поток, например если в неё передать очень много данных. Насколько я помню, с POLLIN и чтением тоже могут бать приколы, но в более сложных случаях: например, если с одного дескриптора идёт чтение в несколько потоков (если я ничего не напутал).

Вот вам цитата Линуса Торвальдса:

yeah, different file descriptor types have somewhat different semantics for «blocking» (with tty's being probably the most complex - think of all the timeout and «minimum character count» and line ending issues with termios).

So the exact detail end up being complicated, but the basic rule of «poll/select goes together with nonblocking IO» still holds. As you saw, mixing poll and blocking IO can «work» but usually has various issues.

It's made more subtle by the fact that poll actually generally tries to help applications be efficient, so if I recall correctly (on my phone right now, no source code) poll will not return writable until the write queues are «sufficiently' empty (something like half empty) so that applications that are in a poll/write loop don't get woken up for each packet that gets sent and acknowledged, but instead get bigger poll sleeps and bigger writes.

So details like that, along with timing etc, makes things much harder to predict. Blocking writes end up » almost working well" except when they don't.

With nonblocking IO, those subtleties all go away.

Если уже добавлять poll перед read, тогда сразу и сокет делать блокирующем.

Не надо советовать человеку плохое. Например, «сработавший» POLLOUT не гарантирует то, что операция записи на блокирующем дескрипторе не заблокирует поток, например если в неё передать очень много данных. Насколько я помню, с POLLIN и чтением тоже могут бать приколы, но в более сложных случаях: например, если с одного дескриптора идёт чтение в несколько потоков (если я ничего не напутал).

Вот вам цитата Линуса Торвальдса:

yeah, different file descriptor types have somewhat different semantics for «blocking» (with tty's being probably the most complex - think of all the timeout and «minimum character count» and line ending issues with termios).

So the exact detail end up being complicated, but the basic rule of «poll/select goes together with nonblocking IO» still holds. As you saw, mixing poll and blocking IO can «work» but usually has various issues.

It's made more subtle by the fact that poll actually generally tries to help applications be efficient, so if I recall correctly (on my phone right now, no source code) poll will not return writable until the write queues are «sufficiently' empty (something like half empty) so that applications that are in a poll/write loop don't get woken up for each packet that gets sent and acknowledged, but instead get bigger poll sleeps and bigger writes.

So details like that, along with timing etc, makes things much harder to predict. Blocking writes end up » almost working well" except when they don't.

With nonblocking IO, those subtleties all go away.

Если уже добавлять poll перед read, тогда сразу и сокет делать блокирующем.

Не надо советовать человеку плохое. Например, «сработавший» POLLOUT не гарантирует то, что блокирующая операция записи не заблокирует поток, например если в неё передать очень много данных. Насколько я помню, с POLLIN и чтением тоже могут бать приколы, но в более сложных случаях: например, если с одного дескриптора идёт чтение в несколько потоков (опять же, если я ничего не напутал).

Вот вам цитата Линуса Торвальдса:

yeah, different file descriptor types have somewhat different semantics for «blocking» (with tty's being probably the most complex - think of all the timeout and «minimum character count» and line ending issues with termios).

So the exact detail end up being complicated, but the basic rule of «poll/select goes together with nonblocking IO» still holds. As you saw, mixing poll and blocking IO can «work» but usually has various issues.

It's made more subtle by the fact that poll actually generally tries to help applications be efficient, so if I recall correctly (on my phone right now, no source code) poll will not return writable until the write queues are «sufficiently' empty (something like half empty) so that applications that are in a poll/write loop don't get woken up for each packet that gets sent and acknowledged, but instead get bigger poll sleeps and bigger writes.

So details like that, along with timing etc, makes things much harder to predict. Blocking writes end up » almost working well" except when they don't.

With nonblocking IO, those subtleties all go away.