форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Семантика EINTR"
Сообщение от vnp on 24-Сен-02, 08:41  (MSK)
(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 на эту тему, киньте ссылку, пожалуйста.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: Семантика EINTR"
Сообщение от Soldier on 24-Сен-02, 10:03  (MSK)
> >(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. А здесь по разному сформулировано не "это", а причина возникновения "этого"
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "RE: Семантика EINTR"
	Сообщение от vnp on 24-Сен-02, 21:11  (MSK)
	>> >>(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'у. Поэтому главный вопрос остается в силе: кто-нибудь видел формальное обоснование такой дискриминации?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: Семантика EINTR"
	Сообщение от Soldier on 25-Сен-02, 08:44  (MSK)
	>Об чем и речь. Дело в том, что select завершается с EINTR >по *любому* >(непойманному) сигналу, в то время как read -- только по SIGINT'у. > >Поэтому главный вопрос остается в силе: кто-нибудь видел формальное >обоснование такой дискриминации? Я не видел формального "обоснование такой дискриминации" :-), но просто давайте взглянем на факты: select - просто проверяет доступность дескрипторов на чтение или запись read   - непосредственно читает из дескриптора, которой может быть и каким-нибудь          устройством По моему (я могу и ошибаться) no comments.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: Семантика EINTR"
	Сообщение от vnp on 25-Сен-02, 12:09  (MSK)
	>>Об чем и речь. Дело в том, что 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, а также любые доказательства правильности такого дизайна.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "RE: Семантика EINTR"
	Сообщение от romanSA on 25-Сен-02, 14:10  (MSK)
	>Об чем и речь. Дело в том, что 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)Нужна возможность динамического изменения числа портов.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.