Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
alex_tr Гость
|
Добавлено: Пт Апр 09 2004 15:03 Заголовок сообщения: сигналы в unix (freeBSD) |
|
|
HELP
В чем может быть проблема:
Посылаю процессу сигнал из драйвера и...
Если процесс как бы активен ( не блокировван фукцией sleep() или getchar() или чем то подобным) , то сигнал принимается и все в порядке.
Если процесс заблокирован sleep() или вызовом какой то подобной функции, то, если в период спячки процесса ему посылается сигна из драйвера система критически падает и перезагружается. |
|
Вернуться к началу |
|
|
rtyuiop Гость
|
Добавлено: Пн Апр 12 2004 14:11 Заголовок сообщения: во бла |
|
|
В общем, опытным путем (в последствии достаточное, но не необходимое объяснение этого казуса нашлось в Бахе) выяснилось, что во freeBSD из драйвера послать сигнал процессу не так просто (точнее невозможно без критического сбоя), если последний в режиме ожидани (sleep, in/out и т.п.).
Выхож:
1) Драйвер перед посылкой сигнала ддолжен проверять в каком состоянии находится процесс, которому этот сигнал посылается.
2) Если в прикладной программе должен быть блокируемый диалог с пользователем и есть необходимость получать сигналы от драйвера, то прикладную прогу надо организовывать состоящую как минимум из двух процессов: один - диалог с пользователем (возможно блокируемый), второй - общение с драйвером через сигналы (желательно без блокироввания - продолжительного блокированя).
Бла - геморой однако со вторым пунктом получился.
Может кто знает опции или флаги, которыми можно устанавливать неблокируемый режим работы процесса без его swap на время блокировки (система падает имеенно из за swap)? Буду благодарен. |
|
Вернуться к началу |
|
|
совсем незнакомый
Зарегистрирован: 24.12.2003 Сообщения: 183 Откуда: Israel
|
Добавлено: Вт Апр 13 2004 09:02 Заголовок сообщения: |
|
|
почему ты выбрал именно сигналы а не другой метод коммуникации ? |
|
Вернуться к началу |
|
|
poioiujh Гость
|
Добавлено: Вт Апр 13 2004 11:19 Заголовок сообщения: какие, например |
|
|
А какой способ еще можно использовать для асинхронного общения драйвера режима ядра и прикладной программы в задачах когда драйвер должен сообщать программе о наступлении какого то события?
1) Общая память или ioctl - опять же это не совсем асинхронный способ (прикладная программа должна сама организовывать алгоритм опроса состояния драйвера, возможно в отдельном процессе)
2) Больше ни чего не придумывается...
Да, может я зря так о невозможности нормально посылать сигналы из ядра в freeBSD и unix в общем (в Linux такой проблемы возможно нет вовсе). У меня версия я дра, с которой приходится работать, довольно древняя, причем код еще и доводился какими то отечественными программерами, которые, по всей видимости, занимались доводкой между очередным и незапланировванным похмельем. |
|
Вернуться к началу |
|
|
совсем незнакомый
Зарегистрирован: 24.12.2003 Сообщения: 183 Откуда: Israel
|
Добавлено: Вт Апр 13 2004 14:10 Заголовок сообщения: Re: какие, например |
|
|
poioiujh писал(а): |
2) Больше ни чего не придумывается...
|
напр. kevent, kqueue
poioiujh писал(а): |
Да, может я зря так о невозможности нормально посылать сигналы из ядра в freeBSD и unix в общем (в Linux такой проблемы возможно нет вовсе). У меня версия я дра, с которой приходится работать, довольно древняя, причем код еще и доводился какими то отечественными программерами, которые, по всей видимости, занимались доводкой между очередным и незапланировванным похмельем. |
не могу сказать, но если нет нужды не работайте на старом ядре. |
|
Вернуться к началу |
|
|
alex_tr Гость
|
Добавлено: Вт Апр 13 2004 15:48 Заголовок сообщения: |
|
|
kevent и kqueue это что такое и как они в общем работают (внешне это напоминает работу с сигналами)? Посмотрю..
Но у меня такое чуство, что это Linuxовые вещи (по названию напоминает).
А вот со старым ядром работать приходится и необходимо, да еще модифицировать его нельзя.
Спасибо за совет |
|
Вернуться к началу |
|
|
|