энди,

поток на этом не останавливается.
Что мешает присвоить Param любое свое значение на выходе из OnExecute?
Этот же Param и будет в финише.

эндиА мне на самом деле сообщения из потока вообще не нужны, мне надо просто запустить и понять в конце выполнения потока были ошибки или нет, вот и все.
Как ты хочешь это понять, если обратную связь не хочешь получать?
Попробуй из наследника TThread поймай exception. :)


П.С. Ты кажется не понял концепцию моего потока: он работает (или спит) до конца работы приложения. Таск - это не поток, это сообщение для потока. Если хочешь обратную связь от таска (сообщения), придется потрудиться написать еще один обработчик. Иначе никак.

makhaonwadman,

авторПопробуй из наследника TThread поймай exception. :)

Я ловлю их и перезапускаю рухнувшие потоки.
Каким образом ловишь?

эндитак почему надо возвращать информацию об ошибке внутри таска именно через messages, а не через finish?
Дак что тебе мешает получить информацию через finish?


В Param в OnExecute ты можешь присвоить что угодно на выходе и оно в финише передастся.

makhaonТак обрабатываются несколько критичных потоков.
Интересный подход, но не лучше-ли если не писать не падающий код, то хотя-бы не убивать и запускать поток лишний раз?

энди1) word передаваемый в start потока, зачем?
Можешь не использовать. Там три варианта Start, один из них без параметров.
энди2) variant в качестве входного параметра не сказать чтобы очень удобен, я привык параметры гонять с помощью коллекций и обычно пользую тупо TParams из db.pas. Он позволяет иметь кучу типов параметров, читаем и пишем как хотим без всякой сериализации/десериализации в Variant
В варианте можно передать и массив. И массив массивов. И т.д. :)
энди3) Зачем вообще все эти входные параметры если можно иметь банальный набор значений в той же форме и зачитать их уже в самом таске. Вопрос многопоточности в этом случае не стоит так как таски выполняются последовательно.
Они выполняются относительно доп.потока последовательно, но для основного потока они выполняются параллельно.
Задача на смекалку:


Какое значение будет в SomeValue, когда запустится таск первый и второй раз?

энди4) Идеальным вариантом параметра для start выглядит имя процедуры которую таск уже запускает внутри себя в отдельном потоке. Тогда не надо на каждый чих заводить отдельный таск.
Этот вариант уже сделан. В обработчике OnExecute, который и является процедурой.

энди,
не понимаю. Предлагаешь урезать функционал под тебя?
Перепиши как хочешь, исходники полностью доступны. Уж извини, что тоже пользуюсь библиотекой и не ограничиваюсь только одним случаем.
И копирование файлов идет фоном в два потока, и непрерывная печать на упаковке, и формирование выгрузок в эксель и т.д.

Докиконки не было в комплекте или она потерялась?
Не было. На кой она? :)

Убрал StopThread (Terminate удобнее).
Добавил возможность стартовать поток 2 из потока 1 с обратной связью в поток 1 (а не VCL/LCL).
Тут нужно понимать, что используется механизм сообщений и обратная связь идет через очередь потока 1.
Убрал жуткую ошибку, которая тянулась с самого начала, но вылезла только на стресс-тесте в внезапным закрытием, когда потоки во всю "общаются".
Ну и исправления по мелочи...

sql2012,

логично. Компонента то шлепнута.
Либо замени слип на работу с проверкой терминатора, либо увеличь интервал ожидания в finishalltasks в деструкторе формы.

Залил на гитхаб: https://github.com/wadman/wthread/

Из последних изменений: поток для синхронного вызова vcl/lcl перевел в режим singleton.
Как раньше не догадался? При большом количестве потоков большой и не нужный расход памяти и дескрипторов.
Теперь таски по умолчанию принудительно прибиваются при Destroy, если не вызвать явно ожидание их работы (FinishAllTasks, WaitAllTasks). Раньше было наоборот.

Добавил TWEvent.WaitForMultiple, который, соответственно, работает только со своим классом.
Подходит для синхронизации нескольких потоков TWThread, TWCThread.