Есть поток, в котором выделены значительные размеры памяти и

← →
Alexander © (2003-09-24 11:59) [0]

происходит ошидание определённого процесса. Как можно прибить этот поток, чтобы освободить всю выделенную память?

Вот код для примера:
function Thread(TR: Pointer): Cardinal; stdcall; var I, N: Integer; Mem: array[0..10000] of Pointer; begin Result := 0; N := -1; try for I := 0 to 10000 do begin GetMem(Mem[I], 100000000); N := I; MessageBox(0, PChar(IntToStr(I + StrToInt(IntToStr(Round(I/2))))), "", MB_OK); end; finally for I := 0 to N do FreeMem(Mem[I]); MessageBox(0, "", "error", MB_OK); end; end; procedure AddThread; var ThreadID: Cardinal; begin hThread := CreateThread(nil, 0, @Thread, nil, CREATE_SUSPENDED, ThreadID); SetThreadPriority(hThread, THREAD_PRIORITY_ABOVE_NORMAL); ResumeThread(hThread); end;

← →
Verg © (2003-09-24 12:13) [1]

> происходит ошидание определённого процесса

Что-то не наблюдается никакого ожидания, особенно процесса...

> Как можно прибить этот поток, чтобы освободить всю выделенную
> память?

Прибить можно - TerminateThread, освободить память - нет.

← →
Alexander © (2003-09-24 12:18) [2]

Ожидание как-раз есть - каждый раз нужно нажать ОK у сообщения.

← →
Alex Konshin © (2003-09-24 12:43) [3]

Гадость какую-то делаешь

← →
Alexander © (2003-09-24 12:48) [4]

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

← →
Alex Konshin © (2003-09-24 12:53) [5]

Жди в потоке правильно. MessageBox там ни к месту.
Создай Event и жди его вместе с другими событиями по WaitForMultipleObjects(Ex).
Основной поток, когда хочет убить тред, выставляет этот Event.
Можно обойтись и одним Event и флагами (выставляещь флаг и Event), короче, решение зависит от задачи.

← →
Alex Konshin © (2003-09-24 12:58) [6]

Если уж так нужно окошко, привязанное к этой нити, то придется создавать его вручную - VCL работает только в основной нити, и заставлять его работать в других нитях - себе дороже.
В этом случае может пригодится MsgWaitForMultipleObjects.
Хотя, мне не совсем ясно, что будет, если из thread вызвать Windows.MessageBox, возможно, что и прокатит.

← →
Digitman © (2003-09-24 13:30) [7]

> Alex Konshin

насчет MessageBox() ты ошибаешься.
вполне допустимо и корректно вызывать эту ф-цию в доп.нити.
к VCL она никак не привязана.

Я по началу его спутал с MessageBox, который из VCL.
Но MessageBox там в любом случае ни к месту.
К VCL-то она может и не привязана, но и прервать-то ее корректно проблематично. Не городить же ради этого цикл обработки сообщений.

> Alexander

код.поток должен быть ответственен за своевременное и корректное освобождение занимаемых им временных ресурсов

лучше всего организовать логику длит.вычислений в поточ.ф-ции в виде цикла (с макс-но короткими по времени итерациями)

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

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

Всем спасибо, буду оптимизировать нормальную обработку остановки сервиса.

Есть поток, в котором выделены значительные размеры памяти и Найти похожие ветки