Нужно соединить две программы по сети. Использую WinSock2, впрочем это не важно. 
В каждой жмем "Соединиться" и начинается процесс соединения (кто сервер, кто клиент выбирается checkbox'ом). Процесс состоит из нескольких шагов, например для сервера они такие:
Проблема в том, что этот процесс должен быть в любой момент отменен, т.е. он должен исполняться в отдельном потоке, чтобы срабатывали controls на форме. В то же время поток должен на каждой стадии выводить состояние соединения в форму, в случае же неудачи на любой из стадий он опять таки должен выполнять код, который должен быть синхронизирован. 

Получается что код метода Execute потока будет выглядеть примерно так:

И мне придется создавать кучу методов аля чтотоТамFailed. А даже если и сделать один метод failed и устанавливать код выхода (failedCode := fcCreateServer), то это тоже кажется страшненьким решением.

Впрочем решения красивее я не вижу. Скажите, есть ли оно? Или, быть может, я неправильно использую потоки?

Я в таких случаях делаю события у потока, т.е. все методы вроде updateStatus или чтотоТамFailed находятся внутри класса-потока, а наружу они выдают обычные события в стиле VCL, например: DownloadFailed(Sender: TDownloader; Reason: TFailReason). Не думаю что лучшее решение есть.

Может проверять на Terminate?



у тебя же есть statusText. Пишешь туда состояние и вызываешь одну процедуру синхронизации updateStatus


почему страшненьким? сделай элементарный обработчик этих выходов:



Внутри server_waitclient() используется, как я понимаю, функция recv(), т.е. блокируящая сокет, то тебе перед ней советую вызывать select() и отлавливать таймауты.

stab, можно чуть подробнее? Вызов типа  ? А как же синхронизация?


да, конечно, но я имел в виду что код функции execute будет как-то страшненько выглядеть


нет, там используется accept:

всё так же, через Synchronize(DoOnStatusMessage), а в DoOnStatusMessage уже собственно сам вызов обработчика события с параметрами.

А в чем тогда коренное отличие от моего способа, кроме того, что вызывается какая-то функция на событие?

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

2. Повышение уровня инкапсуляции, т.к. не требуется объявления в паблик секции свойст вроде StatusText или LastErrorCode, эти данные могут быть просто переданны в обработчик события. В общем, меньше публичных состояний системы - больше надёжности.

Если надёжность\реюсабельность\изменяемость кода не важна, эти два пункта - пустой звук. Всё зависит от контекста и объёма задача.

Многопоточность - как это делается в Дельфи.
Там есть все, чтобы удачно применять потоки  
Пример на твою ситуацию там тоже есть...

stab, прав. Только вот если так делать, то в события неудобно параметры передавать, т.к. в Synchronaze нельзя вызывать метод с параметрами.

Есть еще один вариант.
В поточном классе просто сделал синхронизированные свойства которые отражали бы его состояние и позволяли бы управлять этим состоянием. Типа LastStatus - последний статус, в котором находится компонент. Abort - на следующем цикле метода execute прервать операцию и т.п.

А на форме можно поставить обычный таймер, для того что бы просто отображать текущее состояние...

Это сообщение отредактировал(а) Felan - 2.10.2007, 07:19

этого и так не делается...


Именно это я и имел в виду, когда говорил, что его код от моего мало отличается.


Никакого управления состоянием быть не должно. Код в потоке выполняется последовательно и там нет циклов. 

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

а это тогда зачем statusText := 'Создаем сервер...' ?



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

stab, ты написал:

Я понял это так:

В моем же варианте все то же самое, только в DoOnStatusMessage находится не вызов обработчика, а непосредственно его тело.

Ну так и не делай его. Все остальное ровно то же самое.

Я не пойму чем тебе не нравятся приведенные варианты? Вариант 
stabа,  хорош когда у тебя все на событиях. Мой  - когда нужен постоянно следить за состоянием а индикация уже вторична.

Felan, просто твой вариант мне не подходит, а метод stab'a такой же как и у меня по сути, я просто не вижу разницы между его вариантом и тем, что я привел в первом посте. (кроме, конечно, того, что у него все основано на событиях).

а, ну ок тогда всё. я подумал что тема про события не была понята