Ответ на »сообщение 736« (Санек25)
___________________________
С вопросами -- на Круглый Стол

Привет всем. Есть проблемка напиал программу по обработке текстового файла. Но есть 2 проблемки.
1. обработка файла начинается по событию botton.click. Но как форма становится не активной(напрмер я захожу в мой компьютер и т.п.) то программа сразу зависает и отказывается дальше работать.Файл с которым я работаю 37мб более 2 миллионов строк. Как этого исбежать???

2. Очень долго исправляется файл. В нем примерно 47000 ошибок. и всеэто растягивается на часов 13... Открываю с помощью Tstinglist потом построчно делаю поиск и если нахожу ошибку то исправляю сохраняю в файл.

Ответ на »сообщение 733« (Германн)
___________________________
ОК, на Королевстве иногда хочется почитать не обсуждения каких-то конкретных задач, а более общих рассуждений о разных вопросах, связанных с программированием.
Полный ответ готовлю, но сегодня уже не успею
Да, торопиться-то особо некуда, это же не "помогите, к понедельнику курсовой сдавать надо!" ))
Сергей О.
Завтра, максимум послезавтра, отвечу. Точнее "продолжу обсуждение не вопроса, но темы".

Ответ на »сообщение 733« (Германн)
___________________________
ОК, на Королевстве иногда хочется почитать не обсуждения каких-то конкретных задач, а более общих рассуждений о разных вопросах, связанных с программированием.
Полный ответ готовлю, но сегодня уже не успею
Да, торопиться-то особо некуда, это же не "помогите, к понедельнику курсовой сдавать надо!" ))

Прочитал.
С очень многим соглашусь. Но не со всеми вашими утверждениями.
Подробный ответ требует времени. Пока только скажу, что вы немного "передернули". Моё первое возражение было на ваш совет, что "по хорошему" автору следует использовать доппотоки. А вопрос о выборе асинхронного режима как предпочитаемого появился уже позже.

P.S.
Полный ответ готовлю, но сегодня уже не успею.

Ответ на »сообщение 731« (Сергей О.)
___________________________
Да, вот эти пред. 4 мои сообщения - это было продолжение разговора о COM-порте, который начался здесь:
http://www.delphikingdom.ru/asp/answer.asp?IDAnswer=80767

Что я имею:
-Процессор отнюдь не занят, как предполагал Alexeyslav - программа занимает около 0% процессорного времени.
-Чтение "в штатном режиме" длится ровно столько, за сколько придут заказанное кол-во байтов в порт (пренебрегая накладными расходами).
- Если ошибка чтения (например коммутатор не подключен к компьютеру), то функция возвратится через 200 мс. У меня например в этой задаче состояние коммутатора опрашивается раз в 1 сек. Поскольку чтение происходит в основном потоке, то в ситуации ошибок обмена (коммутатор не подключен и т.п.) примерно 200 мс из секунды программа "висит" и это заметно, например когда её перетаскиваешь по рабочему столу - небольшие скачки, но не создает реальных неудобств. Я считаю, что в нерабочем режиме это вполне допустимо. Нормальный режим программы - когда она подключена к коммутатору и обмен осуществляется нормально.
- Код и его логика простые до неприличия.

Не вижу причин, почему в этой ситуации я должен был бы перейти на асинхронное чтение, где вместо 1 вызова одной функции вызывать
ReadFile, WaitCommEvent, WaitForSingleObject, читать по 1 байту 4 раза (вызывая после приема каждого байта опять функциии ожидания) и потом эти 4 байта складывать в 1 буфер.
Повторюсь, ситуация - специфическая и конкретная, особенности я описал. Но в моей практике подавляющее число задач именно такие. В других случаях чтение вынесено в отдельный поток, но так же происходит синхронно. Но я думаю, что такого рода задач и с другими железками наверное не так уж мало.
Я несколько раз собирался в каких-то задачах перейти на асинхронное чтение, как более идеологически правильное, как "вот если вдруг ситуация изменится и твое синхронное чтение уже не подойдет", но каждый раз в конце концов останавливался на более простом варианте, описанном здесь. Если будет какие-то другие задачи, где приведенный подход будет решать их плохо, приводить к проблемам, тогда наверное придется использовать асинхронный режим.

Для Alexeyslav, попробуйте эксперимент: откройте порт, задайте время чтения большим, секунд 10 (ReadTotalTimeoutConstant := 10000) и вызовите синхронно ReadFile. Если ничего к порту не подключено, то естественно ничего не прочитается, и функция возвратится после конца таймаута. Программа на эти 10 сек зависнет. Но посмотрите с помощью диспетчера задач нагрузку на процессор - она будет 0%. 100% вы получаете  из-за того, что постоянно в цикле вызываете ReadFile, т.е. делаете этот самый поллинг, который Василий здесь не раз ругал. Я решаю задачу иначе, выставляя размер буфера чтения в соответствии с задачей
и выставляя таймауты не "от балды", как написал Германн, а исходя из временных параметров протокола обмена.

Еще раз повторю тезис.
Насчет "синхрона". В каких-то конкретных задачах синхронное чтение вполне нормально решает задачу и решает ее простым способом.
Насчет потоков: и при синхронном и при асинхронном чтении в общем случае стоит использовать дополнительный поток, хотя в каких-то случаях можно обойтись и без этого.

Ответ на »сообщение 729« (Сергей О.)
___________________________
в сообщение попал мусор. Вот этот отрывок без форматирования как код:
  then Result := True
  else EscapeCommFunction(HCom, CLRRTS);
end;
не нужен.

Я не писал, что синхронное чтение хорошо всегда, а написал "простота такого подхода, если он решает задачу". Правильно применение синхронного чтения, по крайней мере в моем опыте, требует правильного задания как раз тех самых таймаутов. Опишу тип задач, которые часто встречаются мне, в управлении изделиями нашей фирмы. Устройство - slave, ждет запроса или команды от компьютера (программы), получив его, отвечает в заданное время (в общем-то - сразу же). Часто длина пакета в обе стороны - не более ~20 байт. Опыт показывает, что ответ (точно не помню. весь обмен туда-сюда или только время ответа, давно измерял) приходит через 60-80 мс. Иногда из-за разных виндовских штучек задержка может быть и немного больше 100 мс.
Как я делаю? В ряде давно написанных программ, которые я поддерживаю и сейчас - один поток. Пишу в порт функцией WriteFile сразу весь пакет, например

type
  TPacket=packed record
    Header: byte;
    Command: byte;
    Data1: byte;
    Data2: byte;
    Data3: byte;
    CtrlSum: byte;
  end;
...
var
  Packet: TPacket;

function SendCommand: Boolean;
var WrRslt: LongBool;
begin
  Result := False;
  BytesWritten := 0;
  if not EscapeCommFunction(HCom, SETRTS)
  then Exit;
  WrRslt := WriteFile(HCom, Packet, SizeOf(Packet), BytesWritten, nil);
  if WrRslt and (BytesWritten = SizeOf(Packet))
  then Result := True
  else EscapeCommFunction(HCom, CLRRTS);
end;

Для чтения задаю таймауты так:

    ReadTotalTimeoutMultiplier:=0;
    ReadTotalTimeoutConstant:=200;

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

type
TStateAnswer = packed array [1..4] of byte;

  then Result := True
  else EscapeCommFunction(HCom, CLRRTS);
end;

Для чтения задаю таймауты так:

    ReadTotalTimeoutMultiplier:=0;
    ReadTotalTimeoutConstant:=200;

Вот пример, где читается 4 байта, в других ситуациях с этим же подходом бывает и 1, и 33 байта например (передача 33 байта на скорости 9600 порядка 30 мс).

type
  TStateAnswer=packed array [1..4] of byte;
...
var
  StateAnswer: TStateAnswer;
...
  ReadSuccess := ReadFile(HCom, StateAnswer, SizeOf(StateAnswer), BytesRead, nil);

продолж. следует

К вопросам оптимизации кода это имеет наверное косвенное отношение, но создавать темы на КД самому невозможно, эта мне кажется более-менее подходящей. Для удобства разобью текст на несколько сообщений.

Тема - про синхронное чтение/запись в Com-порт. В ответ на мои слова
В-третьих никакой причины работать синхронно с изначально асинхронным СОМ-портом нет и быть не может. - Есть причина для этого - простота такого

подхода, если он решает задачу.
Василий написал:
нет ничего хуже, чем в Виндах применять  чисто ДОС-овский синхрон. Причем, этот чудик Билли развивая свое детище все больше и больше делает поблажки

любителям синхрона.
Германн написал:
Вот эта простота как раз та, которая хуже воровства.
Alexeyslav написал:
Синхронный режим хорош своей простотой, но все достоинства тут же и заканчиваются.
Дальше у Alexeyslav были слова про то, что такое чтение тормозит и загружает процессор на 100%, про поллинг (опрос порта каждую 1 мс) и т.д.
Германн написал про таймауты "от балды".

Сначала, ответ на реплику Германна про потоки: когда я написал об отдельном потоке, я не подразумевал именно синхронный режим чтения. Вы сами согласились, что функцию WaitCommEvent стоит вызывать в отдельном потоке. MSDN пишет и Василий в своей статье
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1126
приводит эти слова про вызов этой функции: "при неудаче и при GetLastError=ERROR_IO_PENDING для получения маски эвентов необходимо вначале вызвать Wait-функцию (например WaitForSingleObject) на ожидание установки hEvent структуры lpOver (параметр WaitCommEvent ) в сигнальное состояние.". О чем я и написал, что используются функции WaitForxxx. Насколько я знаю нередко делают так (Василий в своей статье имено так делает): выносят в отдельный поток вообще операцию чтения вместе с функциями ожидания. Т.е. и при синхронном и при асинхронном чтении частно используют дополнительный поток (потоки).

Теперь по поводу синхронного чтения из порта.
Напомню, что синхронное чтение, это когда мы вызываем функцию ReadFile и ждем пока из порта не прочитается заданное в функции кол-во байт или же не выполнится заданное нами условие таймаута чтения. Асинхронное стение - когда функция возвращает результат сразу, а затем мы ожидаем оповещения о том, что что-то прочитано.

продолж. следует.