[Помидоркин]

Еще пара вопросов возникла:
Назначаю процедуру для OnTerminate создаваемого потока

Код:

procedure TForm1.PoolCeate;
var  i: Byte;
begin
 SetLength(FPool,edtPoolCount.Value);
 for i := Low(FPool) to High(FPool) do
 begin
   FPool[i]:= TDLThrd.Create(DlMode,edtURL.Text,Queue,WriteResult); {FreeOnTerminate:= True}
   TDLThrd(FPool[i]).OnTerminate:= Form1.ThrTerminate;
   TDLThrd(FPool[i]).Start;
 end;
end;

procedure TForm1.ThrTerminate(Sender: TObject);
begin
 CS.Enter;
 ListBox1.Items.Append('Поток - '+IntToStr(TDLThrd(Sender).ThreadID)+' - сдох');
 CS.Leave;
end;

Могу ли я быть уверен что поток уничтожен если соответствующее сообщение в ЛистБокс исправно приходит? Дело в том что проверка (в другом обработчике, после того как сообщения от всех потоков пришли) показывает что указатель, во всяком случае, остается

Код:

....
if   Assigned(TDLThrd(FPool[i])) then
...

поискал по вопросу проверки потоков в инете, попался такой вариант

Код:

....
if WaitForSingleObject(MyThread.Handle, 1000) <> WAIT_OBJECT_0 then
.....

покопавшись в этом вопросе немного, наваял такую строку

Код:

....
    if  WaitForSingleObject(TDLThrd(FPool[i]).Handle, 1000) = WAIT_FAILED then
.....

Так вроде бы все встает на свои места, и GetLastError выдает 6, что как я полагаю означает - "Thread Error: Неверный дескриптор (6)".
Но все это мои догадки, хотелось бы услышать мнение специалиста.
И если все так, корректен ли будет такой вариант

Код:

......
   TDLThrd(FPool[i]).OnTerminate:= Form1.ThrTerminate;
.....

procedure TForm1.ThrTerminate(Sender: TObject);
begin
 CS.Enter;
 ListBox1.Items.Append('Поток - '+IntToStr(TDLThrd(Sender).ThreadID)+' - сдох');
 CS.Leave;
TDLThrd(Sender):= nil;  //вариант: Sender:= nil;
end;

Второй вопрос: поток сначала ждет появления задания, далее выполняет их пока список не опустеет и потом самоуничтожается

Код:

procedure TDLThrd.Execute;
begin
 while not FTaskExist do   //Ожидание задачи
 begin
......
 end;

 while FTaskExist do       //Выполнение
 begin
.....
 end;
end;

Такой вариант в моем случае более приемлем чем While not Terminated Do. Но тут есть "маленькие грабельки", если заданий будет меньше чем потоков, те кому не достанется заданий зависнут в цикле ожидания.
Можно конечно попробовать заранее просчитать количество заданий и не создавать лишних потоков, но все же, хотя бы для общего развития, как убить такой поток? Если не ошибаюсь Free вызывает Terminate и WaitFor, а если так то поток все равно останется жить. Вроде бы есть WinAPI функция, но есть мнение что этот способ не кошерный.

[lmikle]

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

ЗЫ. Да, вызов Free не обнуляет указатель, а уничтожает только сам поток. Более того, если ты почитаешь как устроены потоки в WinAPI, то поймешь, что то, что ты имеешь в Delphi не есть на самом деле сам поток, а всего лишь класс-обертка, предоставляющая удобный интерфейс к потоку. Т.е. сам поток может "умереть", а класс все еще существовать, только большинство вызовов буду оканчиваться исключением.

[Помидоркин]

Сообщение от lmikle

... то, что ты имеешь в Delphi не есть на самом деле сам поток, а всего лишь класс-обертка, предоставляющая удобный интерфейс к потоку. Т.е. сам поток может "умереть", а класс все еще существовать, только большинство вызовов буду оканчиваться исключением.

Т.е. может быть ситуация когда, например, указатель все еще существует, но самого экземпляра класса (TThread) уже нет.
Но может быть и ситуация когда класс-обертка все еще жив и обращение TDLThrd(FPool[i]) указывает на вполне себе реальный объект, а самого потока уже нет?
Если так, то как узнать что поток завершился, и убить управлявший им объект?

[lmikle]

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

Как этого избежать? Технически - никак. Это плата за эфективность. Ровно та же беда в C/C++. В managed языках с этим проще, но и в результате эфективность ниже. Т.О. код надо писать с оглядкой на эти особенности. На самом деле это не так сложно, как кажется.