ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
5 декабря
108447 Топик полностью
bialix_ (20.12.2007 18:18, просмотров: 175) ответил Evgeny_CD на ? ->
ну? теорию я знаю. у меня нет опыта написания сферических коней, т.е. библиотек для использования в заранее неизвестном приложении. Цытирую оттуда (предпоследний абзац): "Теперь, но ОЧЕНЬ кратко, залезем в еще большие дебри. Предположим, что протокол обмена с Вашим устройством, подключенным к последовательному порту, очень сложен (передаются большие и сложные структуры данных). При этом Ваша программа должна получать уже полностью принятую и проверенную информацию. Предположим так же, что Ваша программа занимается очень большими и сложными вычислениями и ей нет времени отвлекаться на обработку ввода/вывода. Да и сложность ее такова, что встраивание фонового ввода/вывода сделает ее трудно прослеживаемой и неустойчивой. Чувствуете, куда я клоню? Правильно, к выделению всех тонкостей ввода/вывода в отдельный поток. Возможно выделение и в отдельную задачу, но в этом случае мы не получим никакой выгоды, а накладные расходы на переключение задач гораздо больше, нежели на переключение потоков в одной задаче. " Описан мой случай. Мне и самому понятно, что нужны потоки. Это так сказать внуренности моей либы. Как спроектировать внешний интрефейс? Т.е. как API строить? Мне чиста теортеически кажется, что юзеры должны иметь возможность повесить свои callback на приход новых данных от датчика и возникновении аварийных ситуаций. У меня дивайс -- это датчик. Поэтому юзеры к нему никаких команд посылать не будут. Только получать данные (асинхронно, по внешнему событию) и сигнал о возникновении аварии.