(man select)     EINTR   A non blocked signal was caught.
(man 2 read)     EINTR   The call was interrupted by a  signal before                                                                     any data was read.

Внимание, вопрос: почему это сформулировано по разному?

Если кто-нибудь видел rationale на эту тему, киньте ссылку,
пожалуйста.

• RE: Семантика EINTR,Soldier, 10:03 , 24-Сен-02
  • RE: Семантика EINTR,vnp, 21:11 , 24-Сен-02
    • RE: Семантика EINTR,Soldier, 08:44 , 25-Сен-02
      • RE: Семантика EINTR,vnp, 12:09 , 25-Сен-02
    • RE: Семантика EINTR,romanSA, 14:10 , 25-Сен-02

>
>(man select)     EINTR   A non blocked
>signal was caught.
>(man 2 read)     EINTR   The call
>was interrupted by a  signal before    
>          
>          
>          
>          
>          
>         any data
>was read.
>
>Внимание, вопрос: почему это сформулировано по разному?
>
>Если кто-нибудь видел rationale на эту тему, киньте ссылку,
>пожалуйста.

Семантика (как вы выражаетесь) EINTR везде одна - Interrupted function call.
А здесь по разному сформулировано не "это", а причина возникновения "этого"

>>
>>(man select)     EINTR   A non blocked
>>signal was caught.
>>(man 2 read)     EINTR   The call
>>was interrupted by a  signal before    
>>          
>>          
>>          
>>          
>>          
>>         any data
>>was read.
>>
>>Внимание, вопрос: почему это сформулировано по разному?
>>
>>Если кто-нибудь видел rationale на эту тему, киньте ссылку,
>>пожалуйста.
>
>
>Семантика (как вы выражаетесь) EINTR везде одна - Interrupted function
>call.
>А здесь по разному сформулировано не "это", а причина возникновения
>"этого"

Об чем и речь. Дело в том, что select завершается с EINTR по *любому*
(непойманному) сигналу, в то время как read -- только по SIGINT'у.

Поэтому главный вопрос остается в силе: кто-нибудь видел формальное
обоснование такой дискриминации?

>Об чем и речь. Дело в том, что select завершается с EINTR
>по *любому*
>(непойманному) сигналу, в то время как read -- только по SIGINT'у.
>
>Поэтому главный вопрос остается в силе: кто-нибудь видел формальное
>обоснование такой дискриминации?

Я не видел формального "обоснование такой дискриминации" :-), но просто давайте взглянем на факты:

select - просто проверяет доступность дескрипторов на чтение или запись
read   - непосредственно читает из дескриптора, которой может быть и каким-нибудь
         устройством

По моему (я могу и ошибаться) no comments.

>>Об чем и речь. Дело в том, что select завершается с EINTR
>>по *любому*
>>(непойманному) сигналу, в то время как read -- только по SIGINT'у.
>>
>>Поэтому главный вопрос остается в силе: кто-нибудь видел формальное
>>обоснование такой дискриминации?
>
>Я не видел формального "обоснование такой дискриминации" :-),

"Дискриминация", в данном случае, просто афро-американизм. Не обижайтесь.

>но просто давайте взглянем
>на факты:
>select - просто проверяет доступность дескрипторов на чтение или запись
>read   - непосредственно читает из дескриптора, которой может быть и
>каким-нибудь устройством
>По моему (я могу и ошибаться) no comments.

Вы не ошибаетесь. Все cool. Глядим на факты. Как было замечено выше Вами,
EINTR генерируется при interrupted system call. Как было замечено выше мною, разные system calls are interrupted по разному. Это ли не
дискриминация?

Об одном и том же ли мы говорим?

Почему проверка "доступности дескрипторов на чтение и запись" прерывается
по таймеру, по завершении дочернего процесса... по чьему-то дурацкому
желанию послать мне SIGUSR, наконец; в то время, как "непосредственное
чтение из дескриптора, которой может быть и каким-нибудь устройством", чихало на все, кроме Ctrl-C и иже с ним?

PS Это чистое любопытство. Оно обошлось мне в 9-10 часов отладки. Поэтому
меня больше всего интересует posix rationale, а также любые доказательства
правильности такого дизайна.

>Об чем и речь. Дело в том, что select завершается с EINTR
>по *любому*
>(непойманному) сигналу, в то время как read -- только по SIGINT'у.
>
>Поэтому главный вопрос остается в силе: кто-нибудь видел формальное
>обоснование такой дискриминации?

Во-первых, что происходит по "*любому* непойманому сигналу" можно увидеть в man 7 signal: за редким исключением - это прекращение процесса. Причём вне зависимости read() это или select().
non blocked - это именно незаблокированный, а не непойманный сигнал.
Сигналы блокируются/разблокируются через sigprocmask() и "родственные" вызовы. Блокированные сигналы read()-ом тоже не обрабатываются (насчёт именно SIGINT не помню, см. man sigprocmask).

Формальное обоснование:
read() работает только с одним дескриптором и если на нём есть данные и нет ошибок, то должен их читать.

select() работает с несколькими дескрипторами, причём некоторые могут работать в асинхронном режиме, может проверяться чтение, запись и возникновение особых ситуаций для заданных дескрипторов.
Изменение состояния дескрипторов могут сопровождаться сигналами (напр. при асинхр. операциях).
select() используется как таймер.
select() используется для ожидания одного или нескольких TCP соединения (сначала select() и только потом accept() ).
Всё это многообразие использования (список можно расширить) и привело к такой форме обработки сигналов в select().

Кстати простой пример, где нужно такое поведение select():
1)Есть сервер, ожидающий TCP соединения на N портах.
2)Нужна возможность динамического изменения числа портов.