Я закончил тестирование основных модулей многопоточного COM-порта. И вот, хочу спрсить -- нужен ли такой компонент нам Он совершенно отличается от предложенного, в бытность времен, Wolfik-ом. Обслуживаение порта ведется в Overlapped режиме (режим перекрытия -- это когда поток ждет завершения операций чтения/записи, не тормозя приложение, да еще и в режиме записи уходя в режим остановки потока). На данный момент нет реализации компонентом, есть только отдельные модули, зточенные под конкретную задачу. Сейчас у меня в системе крутится пять таких параллельных модулей, собирая информацию с разных источников. Нагрузка на процессор не повышается и до 1-го процента, даже в пиковой нагрузке

nesco, конечно, нужен! (у меня на компьютере доживают два СОМ порта - сам с собою иногда беседую )

Леонид, много еще оборудования на COM-портах, его и не собираются отменять. То, что его уже нет на PC (шнур поставлют только в Retail поставке, а разъем COM присутствует на материнках), совсем не означает, что его нет на профессиональном оборудовании

+1

э, я не всё понял, но думаю, что нужен (очень)..

А что ты конкретно не понял

Нужен

Tad, а ты че, тоже с портами работаешь

нас это никогда не останавливало но настораживало..

ComAsync вроде тоже не особо тормозил приложение, а вот как будет выглядеть остановка потока - как говорится, ждём подробностей..

наблюдал (со стороны) реализацию подобного (похожего) на С++, работало "как из пушки" в режиме 247, требовалось только периодически, не давать "засыпать" порту ответного устройства..
На мои расспросы автор обронил, что это "стандартные" вещи и внимания заслуживают в последнюю очередь.

P.S.: мои немногочисленные попытки работы с портом упирались в нестабильную или "непрозрачную" (для отладки) работу обоих компонентов. времени для локализации багов, как-то не нашлось, коллег по несчастью тоже, посему - буду рад прогрессу, ибо иногда "старый порт" бывает нужен..

В чем были конкретные проблемы

а я рыжим никогда небыл. Работаю и очень даже.

основная проблема - непостоянство (требовалась круглосуточная работа). я собирал пробный модуль, тестировал его (как видно недостаточно), наматывал "инфраструктуру", запускал в полёт, и обламывался на периодическом непредсказуемом завершении проги. однозначную причину ловить было лень ибо можно было использовать сторонний COM-TCP Server, вот с ним стабильности было много больше.

Возможно, в скором будущем удастся "потестировать" 232-й. Неудобство заключается в сложности отлова бага - "кто сказал МЯУ" - устройству что-то не понравилось, или FPC чудит? особенно при длительной работе..

Вот с FPC мультипотоковый Com работать точно не будет. Ну не нравится FPC несколько одновременных потоков, по крйней мере, в текущей его реализции.
Попробую использовать другую реализацию потока

а может попробовать другую версию FPC в качестве эксперемента...? Может в новой версии с потоками все в порядке

А это уже на совести того, кто будет использовать этот компилятор в качестве базового
------------ Дoбавленo в 03.35:
Посмотрел подробнее компонент от Wolfik-a, там тоже похожие методы перекрыти, но не совсем правильно оформлены и не все до конца сделано. И слишком он навороченный. Мне кажется, такой компонент для несложных задач не совсем подходит, надо что-то попроще, но устойчивее в работе