Насколько я помню select реализован на сис вызове poll ;) Когда работаеш с несколькими дескрипторами применять poll просто не удобно, да и мне кажется что в этом случае select и быстрее и предпочтительнее. Если речь идет о работе с одним дескриптором то poll как раз тот вариант который нужен;)

Хотя я могу и ошибаться.

Good Luck!

в том то и дело, что дескрипторов порядка двух сотен будет и полюбому работать придется с массивом дескрипторов. и в poll() можно цепляться за события

по поводу сравнения:
1. что касается производительности, то, на мой взгляд, это два различных интерфейса одного и того же механизма ядра; т.е. сколько-нибудь существенных различий в производительности быть не должно (и по личному опыту -- нет).
2. что касается удобства, то, на мой взгляд, poll() значительно предпочтительней. код, который будет обрамлять этот вызов, при правильном исполнении будет изящней и компактней.

вопрос в другом: что будет потом с этим кодом? будет-ли он портироваться? эти вопросы нужно решить, перед тем как выбирать между poll() и select().
например, poll() под виндой вообще отсутствует как syscall, а select() под ней -- правильно работает только с сокетами (с остальными дескрипторами работает не правильно).

p.s. вот что к select() у себя на FreeBSD 4.5 прочел:
- For historical reasons, select() will always examine the first 256 descriptors.

для poll() -- такого нет.

select() портабильнее

Прога пишется под линукс и работает с сокетами. Под виндовс-системы портироваться не будет. Спасибо за ответы.

Конечно же poll! Быстрее него будет только система событий, которая пока что есть из бесплатных только во FreeBSD. Но, т.к. под Линукс, то только poll, т.к. он быстрее. Об этом можно почитать.

система событий это имеются в виду сигналы ? я пробывал писать обработчик сигналов, вроде работает, но уж больно код навороченный получается. Так что poll - значит poll ! :)

я так понял что anonym имел ввиду механизм keventов в ядре FreeBSD, который появился если не изменяет память только в 4.2 есть сомнения что на keventах будет быстрее - хотя сей механиз офигенная вещь!

2lg: kevent в FreeBSD и сигналы в линукс принципиально разные механизмы ?

какие еще сигналы? code expample покажи plz
или ты про signal(2)?

допустим так - можно ли через механизм сигналов узнать что у данной вноды поменялось кол-во ссылок на нее?

да я про signal(). все понял, подобные вопросы задавать не буду. пора перебираться под freeBSD.

а так?

а может ли механизм kernel event notification работать с vнодами VFS, (не UFS) ? :)
Думаю, что пока хотябы на этот вопрос нельзя будет ответить утвердительно, нельзя считать kevent офигенным механизмом.
(не подумай, что хаю родную Фрю - отнюдь! но... "правда нам дороже")
ЗЫЖ
>>который появился если не изменяет память только в 4.2
изменяет - в 4.1 ))
ЗЫЖ2
2anonymous> погодь переползать ;)

понимаешь этот механиз может использовать кто угодно .. ты в любой момент работы ядра можешь сгенерировать такой kevent который получет юзер если он его ждет. в vfs генерируеться kevents в async IO рутинах

Не знаю насчет производмительности но select больше 256 дескрипторов не держит.