ну? теорию я знаю. у меня нет опыта написания сферических коней, т.е. библиотек для использования в заранее неизвестном приложении. Цытирую оттуда (предпоследний абзац): "Теперь, но ОЧЕНЬ кратко, залезем в еще большие дебри. Предположим, что протокол обмена с Вашим устройством, подключенным к последовательному порту, очень сложен (передаются большие и сложные структуры данных). При этом Ваша программа должна получать уже полностью принятую и проверенную информацию. Предположим так же, что Ваша программа занимается очень большими и сложными вычислениями и ей нет времени отвлекаться на обработку ввода/вывода. Да и сложность ее такова, что встраивание фонового ввода/вывода сделает ее трудно прослеживаемой и неустойчивой. Чувствуете, куда я клоню? Правильно, к выделению всех тонкостей ввода/вывода в отдельный поток. Возможно выделение и в отдельную задачу, но в этом случае мы не получим никакой выгоды, а накладные расходы на переключение задач гораздо больше, нежели на переключение потоков в одной задаче. "
Описан мой случай. Мне и самому понятно, что нужны потоки. Это так сказать внуренности моей либы. Как спроектировать внешний интрефейс? Т.е. как API строить? Мне чиста теортеически кажется, что юзеры должны иметь возможность повесить свои callback на приход новых данных от датчика и возникновении аварийных ситуаций. У меня дивайс -- это датчик. Поэтому юзеры к нему никаких команд посылать не будут. Только получать данные (асинхронно, по внешнему событию) и сигнал о возникновении аварии.
-
- Ок. Что под руку попалось, то и предложил. Сорри, если не помог. - Evgeny_CD(20.12.2007 20:27)