Доисторический вопрос про прерывания (программерам)(+)

Aleshin · Гуру Зарегистрирован: 18.06.2001 Сообщения: 545

Поликбезьте, если время есть:
помнится, на заре компьютерии, модно было прерываниями пользоваться. Грамотная технология была: прога, вместо того, чтобы тупо тратить свои и без того ограниченные ресурсы, на опрос событий, занималась своим делом. А события (приход в порт, нажатие клавиши и пр.) сами "теребили" прогу аппаратными и программными прерываниями.
Неужели эта перспективная, на мой взгляд, технология, полностью исчезла и я теперь программно должен всех и вся опрашивать?

haali · Гуру Зарегистрирован: 26.09.2001 Сообщения: 708

цитата:
Прислал Aleshin:
Неужели эта перспективная, на мой взгляд, технология, полностью исчезла и я теперь программно должен всех и вся опрашивать?

Нет, похоже, вас кто-то обманул.

/Mike

AE

Мнээээ... Я, честно говоря просто в ступор впал с такой постоновки вопроса

Можно я предварю жалкую попытку ответа вопросом: а вы под Win вообще хоть на каком-нибудь языке вроде паскаля (OWL for pascal, Delphi), C (любой, хоть с плюсами хоть без), Visual Basic (не-VBScript!) и им подобных программы писать пробовали? Так вот, любое GUI-приложение начинается и заканчивается обработчиком событий, приходящих от системы. Если говорить о "механизме прерываний, как о технологии" - то это самая прямая и непосредственная аналогия. А то что это не прерывания - так это есть особенности режима работы процессора и вообще абстрагирование от аппаратного уровня.
И уж начав сравнивать real-mode DOS application и Windows GUI application (не только win, кстати, но и практически всех существующих "user frendly" прокладок между логикой программы и железкой) то в DOS-прерывания - это как правило дополнительный, и не самый удобный механизм работы а обработка сообщений от системы - обязательный. Без обработчика событий WinGUI приложения не бывает Да и вообще Win приложения строятся как правило на событиях и их обработчиках. Пожалуй, единственное исключение - консольные Win32 утилиты.
Вот.
Но, честно говоря, любое введение в любое средство разработки под Win (с помощью которого можно создать многооконное приложение) и ориентированное на совсем-совсем начинающего содержит как раз описание идеологии message'й, handler'ов и цикла обработки событий.
И ситуации, в которых есть необходимость что-то постоянно опрашивать возникают нечасто. И для того чтобы такие ситуации не мешали нормальной работе программы приходится ее распараллеливать, порождая thread'ы в пределах одного процесса или вообще дополнительные процессы - что не сложно, но требует определенных усилий.

Просто буря в стакане какая-то

Рекомендую поставить Delphi или VisualBasic, открыть пример "Helo World", добавить одну кнопку, и добиться, чтобы по нажатию на эту кнопку окно закрывалось. Все станет понятно

P.S.: Не обижайтесь, если я неправильно понял вопрос и на самом деле все не так запущено. Со стороны это именно так выглядит.

Aleshin · Гуру Зарегистрирован: 18.06.2001 Сообщения: 545

Последний раз программировал на Ассемблере для PDP-11 драйвер одной из первых графических цветных плат ;-) соответствующее кол-во лет назад.
Щас попробовал поковыряться в базике, написал прожку. Там действительно все на событиях построено, однако работает настолько медленно, что создается впечатление, что базик своими "подземными ресурсами" и постоянными опросами эмулирует это дело. Ну да хрен с ним, с быстродействием. Для моих дилетанских экспериментов он мне вполне подходил (чрезвычайно прост в освоении и вроде может все). Однако оказалось, что API-функциями пользоваться очень сложно (структур в покет-версии нету, а эмулировать их - очень неблагодарное занятие). А после генерального затыка с IR-портом (ну не хочет базик обрабатывать пресловутые события ентого порта) решил попробовать с С++. Как говорится, не от хорошей жизни.
А для С++ кто-то мне сказал про такую "кощунственную вещь" ;-)

Специально не писал ни в какую продвинутую программеровую конфу, чтобы дилетанскими вопросами не нервировать население, однако и здесь вышло ;-)

AE

Да не, в все нормально

Если вопрос не теоретический а вполне конкретный- то я был не совсем прав

Потому что с IR под WinCE все обстоит хуже. Как нас учит великий и могучий MSDN - есть несколько уровней работы с ИК портом:

на уровне файлового ввода-вывода (IrCOMM): настраиваем последовательное устройство COM3, открываем на нем файл, читаем из него и пишем в него. Поскольку в WinCE не реализован асинхронный файловый I/O, то этом случае действительно придется либо по таймеру (тоже системный объект, который посылает приложению события по времени ) опрашивать состояние файла, либо в отдельной нитке (thread) вызывать WaitCommEvent. При этом WinCE сама обрабатывает низкоуровневые ошибки в соответствии с спецификациями IrDA;
Прямая работа с IR (Raw IR): практически здесь данныеотправляются и получаются напрямую на ИК порт. Все коллизии, пропадания сигтала и т.д. нужно обрабатывать самому;
IrSock - полностью соответствует событийной модели, асинхронен, но является надстройкой над IrCOMM со всеми последствия

Все эти проблемы с синхронностью - результат "усеченности" WinCE. В случае с Win32, например, есть еще пара вариантов работы с последовательными устройствами в асинхронном режиме: Overlapped file I/O и Telephony API (TAPI) (бррррр...)

Опять-таки, как учит MSDN с соответствующим примером, для WinCE достаточно просто реализуется эмуляция асинхронного I/O. И идея тоже прозрачная: порождаем вспомогательный thread, который не блокируя программу отслеживает состояние IR, а при возникновении каких-либо событий (получение/завершение передачи данных, ошибка и т.д.) посылает приложению соответствующее сообщение.

Вот. Какой из вариантов выбрать - зависит от ситуации, но на VB достаточно просто реализуется только первый. Для остальных - VC. Может еще что есть не от Microsoft'а

Ааа, вот еще один вариант: у MS для "больших" PC есть ActiveX обьект COMPort в котором реализована вся рутина. Может и для WinCE такое есть? Решило бы все проблемы и без C. С прерываниями

Aleshin · Гуру Зарегистрирован: 18.06.2001 Сообщения: 545

Дык есть такой контрол в Базике. КомПорт. Который я знаю как облупленный и вовсю использую, чтобы получать NMEA-данные из ЖПС по проводу. Работает все отлично. А вот как только настраиваешь его на ИР - ничего слышать не хочет.
Главное, при инициализации и начале работы в телефоне (сотовом), который на ИР смотрит появляется шевеление, типа "есть несущая". Но на этом все и заканчивается. События не отрабатываются, различные принудительные меры и опросы тоже ничего не дают.
Полазил по забугорным конфам - у всех такая проблема, никто толкового ничего на эту тему не пишет.
Прям западло!
А связываться с ИрСоком что-то сильно геморно, а потом, неизвестно, как на это дело отреагирует телефон (мобыть он попроще на жизнь смотрит ;-)

Alex Muratov

Увы, некоторые вещи в Win32 делаются геморно. Так что мой прогноз - придется вам общаться с IrComm, со всеми последствиями.