У меня один коротенький поток вызывается главным окном каждые 2 секунды. Логично освобождать из-под него память. Однако если FreeOnTerminate = true,  то возникает исключение примерно такого содержания:
"... raised exception class EOSError with message 'System Error. Code: 6. Неверный дескриптор'". Прямо так по-русски и пишет - неверный дескриптор.
В классе потока есть три перменные, но я вроде к ним нигде кроме как из самого потока не обращаюсь, тем более после его завершения.
В чём может быть проблема?
Что это за класс EOSError?

А после того, как отрабатывает, Вы его заново создаете?

Создаю его по событию таймера. Событие возникает каждые 3 секунды  (а не 2 как раньше написал, извиняюсь). За это время он успевает завершиться.

Но это наверно неважно, так как возникает исключение на первом же экземпляре потока (только не знаю именно в момент завершения или нет).

А вообще если он не успеет завершиться за 3 сек. И по таймеру будет создан второй поток, он не будет конфликтоватьс первым? Или это будет неправильно?

Это сообщение отредактировал(а) ksili - 12.3.2007, 11:13

Без кода врядли что можно сказать путное

Код, конечно, в таких вопросах ОБЯЗАТЕЛЬНО надо приводить... Навскидку можно предположить, что при завершении потока вызывается последовательность Thread1->Terminate и затем Thread1->Free (или как-то аналогично). При установленном свойстве FreeOnTerminate = true вторая команда фактически будет освобождать уже автоматически особожденный (при Terminate) участок памяти, что приводит к AV.

Посмотрел в диспетчере задач без FreeOnTerminate = true. Вроде всё нормально один процесс создаётся и через некоторое время убивается. Память тоже освобождается и выделяется (больше не становится). Так что ложная тревога. Всем спасибо за внимание

А причем тут процессы  Речь идет об уничтожении объекта класса после завершения процесса. То есть у Вас (если Вы конечно не уничтожаете  объект сами ) будет накапливаться утечка памяти.
Правда по завершению программы конечно все освободится ( WIn32 как никак  ).  Но согласитесь, что такой подход некрасив : new без delete

Добавлено @ 13:21 

Это Вы по диспетчеру задач определили ? Мда. А Вы не пробовали  спросить мнение на этот счет у CodeGuard? Думаю, он будет против. 

Так значит правильная последовательность работы с потоком примерно такая:

?

Если так написать, то память будет освобождаться и на флаг FreeOnTerminate можно не обращать внимание? Я правильно понял?

Это сообщение отредактировал(а) ksili - 13.3.2007, 07:37

Для потока с FreeOnTerminate = true; завершение делается так:

Видимо если FreeOnTerminate = false; надо добавить delete td;

Идея то правильная.  И тут все будет очищаться правильно. Только в с логикой напряги.  Вы запускаете поток, а потом тормозите основной до момента, пока не выполнится дочерний. Смысл? Не проще тогда выполнить все действия в основном потоке? Все равно при работе дочернего он простаивает  
Я пока не могу понять одно. Почему у Вас не работает это ?

Вы случаем после этих строчек не пытаетесь написать что-то вроде

или то, что  pandrew указал? Этого делать ни в коем случае нельзя. К моменту  обращения  к объекту td после того как уже вызван  Resume() поток может выполнится, а объект, соответственно, уничтожен  и Вы будете обращаться к несуществуещему объекту

Добавлено @ 13:17 

Грубая ошибка. Во-первых к моменту вызова Terminate поток может уже завершиться и td уничтожиться. Во-вторых, даже если поток еще работает, то он может успеть завершиться и уничтожиться после Terminate, но  до вызова  WaitFor.

Сейчас уже кода перед глазами нет, завтра погляжу повнимательнее и отвечу.
А почему нельзя после Resume() писать WaitFor()? Когда вообще тогда WaitFor() писать нужно?

ksili, сможешь аргументировать применение потоков в своей задаче?

Я согласен, что WaitFor использовать в основном потоке неправильно, так как это тормозит всю прогу и сводит на нет все преимущество от использования потоков.

Теперь попробую аргументировать применение потоков в моей задаче.
В системе есть много COM-портов. Программа должна опрашивать те которые инициализированы (сейчас при отладке экспериментирую только с одним) на предмет того, что на них что-то поступило. Если поступило, то она сохраняет инфу об этом в специальной таблице БД. 
Есть ещё несколько потоков, которые периодически смотрят в эту таблицу и если там что-то есть, то отрабатывают это событие.

То событие таймера (раз в 3 сек)  о котором я говорил выше, перебирает все порты и запускает для каждого инициализированного порта поток, к-рый его опрашивает.

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

Я сейчас уже подумал, что правильнее будет не создавать эти потоки каждые 3 секунды, а создавать поток на каждый инициализированный порт, который будет его опрашивать постоянно:



Это сообщение отредактировал(а) ksili - 14.3.2007, 06:01

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

сам поток в таком виде работает нормально:

while(!Terminated)
        {

               if(WaitCommEvent(Form1->hCom,&dwCommEvent,NULL))               

                if(ClearCommError(Form1->hCom,&dwError,&COMSTAT))
                    dwRead=COMSTAT.cbInQue;
                                  {
                                          while (dwRead)
                                       {
        ReadFile(Form1-hCom   lpBuffer1,dwRead,lpNumberOfBytesWritten, NULL);
                        
                        Form1->Nsect=Form1->Data.RecByte1
                        Form1->Fh=(Form1->Data.RecByte2)+((Form1->Data.RecByte3)*255);
                                        
                        Form1->Label20->Caption=IntToStr(Form1->Data.RecByte1);
                        Form1->Label21->Caption=IntToStr(Form1->Data.RecByte2);
                        Form1->Label23->Caption=IntToStr(Form1->Data.RecByte3);
                        Form1->Label24->Caption=IntToStr(Form1->Fh);
                          
                                         }
                                   }
        }

но при попытке его подвесить из основного потока все виснет. 

Всё, что обращается к основной форме


надо поместить в отдельную функцию класса потока и вызывать её при помощи метода потока Synchronize. посмотри хелп на Synchronize