Как определить, пуст ли stdin

man select

Лучше man poll

Фломастеры. Мне poll не нравится. Уродище какое-то.

На тебе готовье: tty + терминал, только терминал.

Согласен. Поэтому придумали epoll.

Еще хуже. Буээээ.

Ну давай, обоснуй.

Посмотри на размеры кода с select и с epoll, выполняющего идентичную задачу. Я примеры привел.

Ну так ведь getchar же будет ждать появления данных на входе - а мне надо до появления продолжить работу по старым. Пока изучаю наброшенное.

На самом деле, все зависит от задачи. Когда у тебя 2-3 дескриптора, то и select'a хватит, а если 2k-3k, то тут уже с epoll будет сильно удобней.

Смотрю на свой код с epoll — мало и понятно. По-твоему, старый медленный механизм с API на дефайнах рулит?

2k stdin-ов, о времена, о нравы!

если 2k-3k

Я вообще не представляю, нафиг такое убожество лепить, чтобы больше десятка дескрипторов было! Про pthreads не слыхал, да?

Старый, надежный и рабочий. Новое нужно лишь если оно объективно лучше старого.

Он, похоже, имел в виду черезжопное решение сервера: когда вместо потока на каждое соединение создается пулл дескрипторов и с этим бешеным количеством вручную трахаются, вместо того, чтобы поручить секс ведру!

Про pthreads не слыхал, да?

2k-3k потоков, что ли? :) Смишно ...
А нафиг нужно - да хотя бы web сервер, тот же nginx тебе в пример.

Да и что будет быстрей и менее затратно по ресурсам, поток на каждый коннект или добавить дескриптор в epoll ? :)

Он имел в виду правильное решение для задачи большого числа коннектов, но это бесполезное усложнение в случае ТС. Твое предложение использовать по потоку на коннект на большом числе коннектов и данных не выдерживает критики, но тебе это простительно – ты звездочет.

Так тебе с еполом придется еще и создавать пул задач. Т.е. вручную рулить кусками памяти, malloc/realloc/free... Нафиг. Пусть этим ведро занимается!

Nuff said.

Короче, не парь человеку мозг!

Если он вдруг дорастет до highload, тогда пусть хоть епол изучает. А в реальной жизни это нахрен не нужно. У меня, например, мои CGI сишные никогда не испытывают даже половинной нагрузки, т.к. максимум 2-3 соединения бывает!

Инструмент под задачу надо выбирать, однако!

когда вместо потока на каждое соединение создается

Убиват и закапыват.

Почитай мое сообщение ниже твоего и подумай, прежде чем бред нести!

Почитал. Передумал.

Убиват, сжигат сердце и только потом закапыват.

если новых данных нет

перевод с ньюфаговского: истёк таймер ожидания

Если человеку сразу не объяснить, как делать правильно и почему, из него вырастет Эдик.

Ты кстати забыл объяснить, почему узкоспециализированный линуксовый epoll лучше кроссплатформенного select-a. Дерзай, если не балабол.

узкоспециализированный

А это ты почему так сейчас решил?

Как я понимаю, он создавался для решения проблем перформанса, да, узкоспециализированный – плохое слово для этого. Может я и в этом не прав, поэтому

Если человеку сразу не объяснить, как делать правильно и почему, из него вырастет Эдик.

все же объясни.

Я все делаю так, как мне хочется. И мне насрать на чужое мнение, если только это чужое мнение не по делу. Сейчас совсем не по делу. Мне eselect никогда не нужен будет — я не погромист и уж highload точно заниматься не собираюсь! В моих задачах зачастую вообще 1 соединение на демон...

все же объясни

++

Пусть подробно изложит, с какого это хрена на задачах с 1-2 дескрипторами нужен epoll вместо select!

1. простой API;
2. быстрее работает.

Недостаточно? Если нужна кроссплатформенность, есть либо библиотеки, которые абстрагируют ещё выше, либо ifdef'ы.

Напомню на всякий случай, что в BSD есть «узкоспециализированный» kqueue (который ещё круче, если верить тому, что пишут).

Чтобы потом не переписывать, а использовать готовую обёртку вокруг epoll.

Ты истеришь, похоже.

Недостаточно?

Недостаточно. Я то же самое могу про select сказать. И API у select, между прочим, значительно проще! И работает наверняка шустрей, т.к. проще.

Чтобы потом не переписывать

Зачем? Зачем переписывать то, что и так отлично работает?

И работает наверняка шустрей, т.к. проще.

facepalm.mkv.

пока народ замкнуло на epoll vs select :-)

есть много способов других сделать то что хочет ТС

• поставить флаг O_NONBLOCK и наслаждаться read`ом - если нет ничего так ничего и не прочтётся (сразу вернётся -1 и errno=EAGAIN)
• без O_NONBLOCK - перед вызовом read взвести таймер и выставить маски сигналов. Если read осуществляется слишком долго, то таймер счёлкнет и вернётся -1 при errno=EINTR
• через fcntl навесить сигналы на приход данных. Как только чтение станет возможным придёт сигнал в котором например можно выставить флажок.

Ты помассируй лицо, помассируй. Очень от морщин помогает.

P.S. Если бы Стивенс писал подробно про epoll, я может и epoll юзал бы...

Изо всех сил стараюсь. На таких, как ты, ни лиц, ни рук, ни морщин не хватит.

man 7 epoll, куда уж подробнее. Даже примеры с вопросами-ответами есть.

http://stackoverflow.com/questions/17355593/why-is-epoll-faster-than-select

tl;dr: селект ставит/снимает тред во столько очередей, сколько дескрипторов в сете; O(n). Еполл сам по себе агрегирущий дескриптор, поэтому ждущий тред ставится только в одну очередь; O(1). Кроме того, селекту приходится опрашивать дескрипторы, а еполл автоматом знает об их активности.

а еполл автоматом знает об их активности.

кулстори.

Ironically, with select, the largest cost comes from checking if sockets that have had no activity have had any activity. With epoll, there is no need to check sockets that have had no activity because if they did have activity, they would have informed the epoll socket when that activity happened. In a sense, select polls each socket each time you call select to see if there's any activity while epoll rigs is so that the socket activity itself notifies the process.

Почему это не так?

кроссплатформенного select-a

*Кхм, вспоминая про винду* не такой и кроссплатформенный. Сорри, что влез в вашу дискуссию.

простой API;

Субъективно, сложнее select-а.

быстрее работает.

Для одного дескриптора разница несущественна, в рамках задачи ТС вообще не имеет смысла.

Недостаточно? Если нужна кроссплатформенность, есть либо библиотеки, которые абстрагируют ещё выше, либо ifdef'ы.

Конечно нет. Видимо следовало предложить эти самые библиотеки, потому что вариант втыкать системно специфичные сисколлы и обкладывать их дефайнами вообще не вариант. Пока что твой единственный объективный аргумент актуален разве что для с10k.

Короче, ты прям антипод Эддика, любишь переусложнять.

Я люблю универсальное, новое и быстрое.

epoll это красиво, модно, молодёжно..помнится возник он в момент когда стало ясно что поддержка POSIX AIO в ядре излишне гиморно, а на уровне библиотеки через select или треды вообще нонсенс. epoll смержили в ведро, но лучше не стало; зато теперь имеется 3 (три карл!) взаимозаменяемых механизма. Есть овеяный стандартами и историей select, есть бедный aio, есть быстрый геморой epoll.