Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / C++ [игнор отключен] [закрыт для гостей] / Проверка select'ом на запись. / 14 сообщений из 14, страница 1 из 1
06.10.2006, 18:02
    #34038718
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Кто-то юзал такое?
Пишу сразу по 2 раза в pipe. Сначала проверяю селектом, а потом пробую записать. Так вот, на 2-м разе, мне селект возвращает 0, и можно ждать соколько угодно долго, а если им не проверять, то все записыватеся великолепно. В чем может быть дело?
Файловые дескрипторы правельные, параметры тоже.

ОС linux
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2006, 12:52
    #34039354
Tubrik
Tubrik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
а можно сам селект поглядеть?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 10:29
    #34040793
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Ну, да:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
fd_set fs;
struct timeval tv

FD_ZERO(&fs);
FD_SET(pp[nPipe][ 1 ]);
tv.tv_sec= 0 ;
tv.tv_usec= 10 ;//Сюда, хоть час пихай, не аукнется

select(pp[nPipe][ 1 ]+ 1 , NULL, &fs, NULL, &tv);
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 10:40
    #34040835
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Да, кстати, можно ли как-нибудь pipe сдалать не блокирующим?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 11:16
    #34040972
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Сложилось впечатление, что селект на реад, возвращает 1, если труба пустая или последняя операция была на считывание. Блокировка же на запись происходит, когда в требе 512 записей или 2К данных (что-то из этого). В документации написано, что трубы являются блокирующими. Значит, наверное, с этим ничего поделать нельзя. Тогда может можно как-нибудь узнать на сколько заполнилась труба?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 11:26
    #34041001
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
AkhДа, кстати, можно ли как-нибудь pipe сдалать не блокирующим?


Код: plaintext
1.
int result=fcntl(fd,F_SETFL, O_NONBLOCK);
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 11:40
    #34041065
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
AkhСложилось впечатление, что селект на реад, возвращает 1, если труба пустая или последняя операция была на считывание. Блокировка же на запись происходит, когда в требе 512 записей или 2К данных (что-то из этого). В документации написано, что трубы являются блокирующими. Значит, наверное, с этим ничего поделать нельзя. Тогда может можно как-нибудь узнать на сколько заполнилась труба?


Так:
Код: plaintext
1.
2.
int s_rsz;
int result=ioctl(fds, FIONREAD , &s_rsz);
для сокетов работает, думаю должно работать и для пайпа.


И в качестве идеи(Сам еще не пробовал)
Можно попробовать открыть перехват SIGIO.
А по приходу сигнала читать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 11:45
    #34041085
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Пасибо, буду эксперементировать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 12:34
    #34041283
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
AkhПасибо, буду эксперементировать.

Я понял почему второй селект не возвращает управление.
Он ловит SIGIO и сбрасывает флаг сигнала.
Пока в пайпе не появятся новые данные( придет новый SIGIO)
select управления не вернет, не смотря на то
что в буфере еще остались данные от предидущего чтения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 12:56
    #34041368
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
onstat- AkhПасибо, буду эксперементировать.

Я понял почему второй селект не возвращает управление.
Он ловит SIGIO и сбрасывает флаг сигнала.
Пока в пайпе не появятся новые данные( придет новый SIGIO)
select управления не вернет, не смотря на то
что в буфере еще остались данные от предидущего чтения.

Как-то это криво, через сброс флага, получается, что двойной чеккинг не возможен? Все сходится, но тогда работа селекта кажется корявой.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 17:10
    #34042395
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Akh onstat- AkhПасибо, буду эксперементировать.

Я понял почему второй селект не возвращает управление.
Он ловит SIGIO и сбрасывает флаг сигнала.
Пока в пайпе не появятся новые данные( придет новый SIGIO)
select управления не вернет, не смотря на то
что в буфере еще остались данные от предидущего чтения.

Как-то это криво, через сброс флага, получается, что двойной чеккинг не возможен? Все сходится, но тогда работа селекта кажется корявой.

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

Операция чтения тоже работает с этими флагами,
и часть ответственности за то, что повторый select ничего
не возвращает лежит на ней.

Чесно говоря, кто сбрасывает флаг готовности я не знаю, нужно будет проверить, сейчас времени нет.
Вполне может быть, что и read.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 17:37
    #34042497
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
onstat-Если программа зделала чтение
то сама может получить состояние дескриптора(синхронный режим).
по завершению операции.
И приять решение осталось ли что то еще в буфере, или нет.
Ей же вернули готовый дескриптор, а сколько нужно читать
и сколько будет прочитано это уже не дело select.

Операция чтения тоже работает с этими флагами,
и часть ответственности за то, что повторый select ничего
не возвращает лежит на ней.

Чесно говоря, кто сбрасывает флаг готовности я не знаю, нужно будет проверить, сейчас времени нет.
Вполне может быть, что и read.

Вообще, то я думал, что это ее дело. Я допустим узнаю, что можно прочитать блок и начну читать. Реад мне вернет сколько сможет, но не более, чем я запросил. А вот второй раз читать мне уже должно становиться страшно, а вдруг поток заблокируется.

Но дело совсем не в чтении; с чтением, как раз все нормально и select по всей видимости хорошо с этим работает (все-таки, возвращает идентификатор трубы). Проблема, аналагичная рассуждаемой, возникла именно с write.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2006, 18:35
    #34042687
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
Akh onstat-Если программа зделала чтение
то сама может получить состояние дескриптора(синхронный режим).
по завершению операции.
И приять решение осталось ли что то еще в буфере, или нет.
Ей же вернули готовый дескриптор, а сколько нужно читать
и сколько будет прочитано это уже не дело select.

Операция чтения тоже работает с этими флагами,
и часть ответственности за то, что повторый select ничего
не возвращает лежит на ней.

Чесно говоря, кто сбрасывает флаг готовности я не знаю, нужно будет проверить, сейчас времени нет.
Вполне может быть, что и read.

Вообще, то я думал, что это ее дело. Я допустим узнаю, что можно прочитать блок и начну читать. Реад мне вернет сколько сможет, но не более, чем я запросил. А вот второй раз читать мне уже должно становиться страшно, а вдруг поток заблокируется.

Но дело совсем не в чтении; с чтением, как раз все нормально и select по всей видимости хорошо с этим работает (все-таки, возвращает идентификатор трубы). Проблема, аналагичная рассуждаемой, возникла именно с write.

1. По идее если установлен режим O_NONBLOCK, write должен вернуть ошибку
(не проверял).
2. Нужно разрешать и ловить SIGIO.
3. Заказывать SIGALARM, если дескриптор заблокируется,
сигнал разбудит процесс.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.10.2006, 09:56
    #34043316
Akh
Akh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка select'ом на запись.
onstat-Вообще, то я думал, что это ее дело. Я допустим узнаю, что можно прочитать блок и начну читать. Реад мне вернет сколько сможет, но не более, чем я запросил. А вот второй раз читать мне уже должно становиться страшно, а вдруг поток заблокируется.

Но дело совсем не в чтении; с чтением, как раз все нормально и select по всей видимости хорошо с этим работает (все-таки, возвращает идентификатор трубы). Проблема, аналагичная рассуждаемой, возникла именно с write.

1. По идее если установлен режим O_NONBLOCK, write должен вернуть ошибку
(не проверял).
2. Нужно разрешать и ловить SIGIO.
3. Заказывать SIGALARM, если дескриптор заблокируется,
сигнал разбудит процесс.[/quot]

Не уверен, что для пипей можно делать O_NONBLOCK (я так понимаю, через iocntl), т.к. в документации пишется, что они блокирующие.
На счет 2-го и 3-го пунктов, получается, что высокоуровневыми средаствами с пипями работать нельзя.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / C++ [игнор отключен] [закрыт для гостей] / Проверка select'ом на запись. / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 367ms
Закрыть
start [/forum/topic.php?fid=57&mobile=1&tid=2030327]:
 0ms
get settings:
 4ms
get forum list:
 8ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 132ms
get topic data:
 6ms
get forum data:
 1ms
get page messages:
 24ms
get tp. blocked users:
 1ms
others: 187ms
total:  367ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]