Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Дополнительный поток и Exception в главном. Что будет?

Страницы: < 1 2 3 4 5 6 7 >
Kolan © (2006-10-15 22:43:00)
Здравствуйте,
В программе есть доп поток. Что будет с доп. потоком если в гл. потоке произойдет Exception?

Percent (2006-10-16 20:06:00) [21]
Вот я и спрашиваю можно ли замутить с формой?

Перефразируй, пожалуйста...

Kolan (2006-10-16 20:01:00) [22]

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

> Leonid Troyanovsky © (16.10.06 19:42) [110]
>
>

Благодарю. Идея понятная. Буду пользоваться.
Но в денном случае, опираясь на ваш код. В
Synchronize(ShowResult);мне надо лишь отправить пакет дальше... и Тут же вернуться. Те никаких исключений в потоке не будет.

Вот я и спрашиваю можно ли замутить с формой?

> Ну, и не должны потоки быть suspended.
> Это для потока не рабочее состояние, а скорее отладочное.
>

Буду медетировать на это.

Leonid Troyanovsky (2006-10-16 19:42:00) [23]

> Kolan © (16.10.06 18:12) [106]

> Как перепроектировать?

До главного менеджера боюсь, что не осилю, но,
для обработки ошибок в потоке могу предложить такой паттерн:
type EThreadException = class(Exception); TMyThread = class(TThread) procedure Execute; override; private .. Error: Exception; procedure ShowError; procedure ShowResult; end; procedure TMyThread.ShowExcept; begin Application.ShowException(Error); end; procedure TMyThread.Execute; begin while not Terminated do try .. raise EThreadException.Create('...'); // если что-то не так .. Synchronize(ShowResult); // показываем результат .. except on E: EThreadException do // мы знаем, как исправить ситуацию begin Error := E; Synchronize(ShowExcept); // если нужен показ {корректирующие действия} end; on E: Exception do // мы не знаем, как реагировать на другие ошибки begin Error:= E; Synchronize(ShowExcept); // показываем исключение Terminate; // завершаем поток end; end; end;

Что произойдет, если исключение возникнет в ShowResult?
Если внутри метода нет обработчиков, исключение попадет в except потока. Если это известное исключение (EThreadException), то его можно
обработать и, возможно, поток продолжит работу.

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

Схема может быть использована непосредственно
для тех потоков, которые отзываются на Termianate.
А, например, поток, ожидающий в ReadFile ввода не в состоянии
реагировать на установку Terminated, т.е., нуждается в
дополнительных управляющих сигналах.

Ну, и не должны потоки быть suspended.
Это для потока не рабочее состояние, а скорее отладочное.

--
Regards, LVT.

Percent (2006-10-16 19:39:00) [24]
1. Есть главный менеджер в который композитно входит менеджер измерений(Он знает логику измерения).
2. В менеджере измерений есть менеджер устройства, который знает о протоколе.
3. Менеджер устройства использует менеджер связи(TConnectionManager), который обрабатывает данные и отправляет в порт.

И в чем проблема? Каждый менеджер пусть обрабатывает свой участок работы.
1. Менеджер связи - отсылает пакеты и ждет приходящих пакетов. Сделай у него события OnConnect, OnDisconnect, OnPacketReceived, OnError. И метод отправки пакета.
2. Менеджер устройства - пусть собирает пакеты для отправки и разбирает пакеты при пролучении.
3. Менеджер измерений пусть анализирует принятую информацию. И подготавливает данные измерений.

Ты бы хоть бы название софта озвучил бы. И логику его работы описал. То есть, для чего это все?

Kolan (2006-10-16 19:13:00) [25]
Короче, потом не говорите, что плохо :)
TConnectionManager- точно должен быть фасадом. У него всего две функции предать пакет и выдать принятый, а там хот через сеть может передаваться. Делаю короче через окно(окно-поле этого менеджера) и сплю спокойно...

Kolan (2006-10-16 18:22:00) [26]
Те я ка бы последовательно пользуюсь паттерном фасад.

Kolan (2006-10-16 18:12:00) [27]

> бр-р-р. что-то мне подсказывает, что ты спроектировал софт
> "от балды", совершенно не представляя, зачем там потоки,
> и что они должны делать. и как, собственно, вся эта механика
> работает.

Все же некоторое представление о том что там да как имею. :)

> Kolan © (16.10.06 12:17) [103]

Дык это брр?

Итак я получил пакет. Как мне сделать дальше. Как спроектировать?

procedure TConnectionManager.PackageReceivedEvent(Sender: TObject; Package: array of Byte); begin if Assigned(FConnectionManagerPackageReceivedEvent) then FConnectionManagerPackageReceivedEvent(Self, Package); end;

Система примерно такая
1. Есть главный менеджерв который композитно входит менеджер измерений(Он знает логику измерения).
2. В менеджере измерений есть менеджер устройства, который знает о протоколе.
3. Менеджер устройства использует менеджер связи(TConnectionManager), который обрабатывает данные и отправляет в порт.

Так вот форма в лучшем случае знает о Главном менеджере. Как быть? Сообщение посылать неудобно.

Как перепроектировать?

Ketmar (2006-10-16 17:46:00) [28]
бр-р-р. что-то мне подсказывает, что ты спроектировал софт "от балды", совершенно не представляя, зачем там потоки, и что они должны делать. и как, собственно, вся эта механика работает. сорри, но у всех вопросов лапы растут явно оттуда. есть предложение: выспаться, плотно подумать и переписать всё заново. %-)

Kolan (2006-10-16 12:30:00) [29]
и сообщени передать Self те указательна экземпляр TConnectionManager, а форма вызовет:
TConnectionManger(Pointer).ProsessPackage// Ну или как там правильно преобразовать указатель в объект.

В итоге дальше модуля с TConnectionMangerдело не пойдет. И Synchronize закончится быстро. :)

Но ответа я дождусь, а то опять перепахивать все :)

Kolan (2006-10-16 12:17:00) [30]
Может мне для передечи сообщения, чтобы все осталось внутри модуля и не трогало гл. форму, создать формочку прямо в TConnectionManager

Те
TConnectionManager = class FForm: TForm;

А получив пакет я его скопирую и пошлю сообщение

procedure TConnectionManager.PackageReceivedEvent(Sender: TObject; Package: array of Byte); begin //Копирую PostMessage(); end;

Нормальный маривант?

Сергей М. (2006-10-16 12:12:00) [31]

> Kolan © (16.10.06 11:54) [101]

> ветку ниасилили

Эт точно)
В ней много шуму из ничего.

Если не вдаваться в подробности изначальнонеразумно спроектированной тобой логики разделения функциональности приложения (между потоками ее процесса), то ответ на вопрос был уже дан, и он прост как 2х2:

try
synchronize(...)
except
... //никаких re-raise, если отсутствует перехват и обработка исключений уровнем выше !
end;

Kolan (2006-10-16 11:54:00) [32]

> suspend твой в доп.потоке - тоже по статье ?)

Причем тут это??? Я понимаю ветку ниасилили :)

Мы тут говорим НЕ о ПТОКЕ ЧНЕНИЯ ИЗ ПОРТА(который ессно не спит), а о другомпотоке, Который ищет в полученых из порта данных пакет.

Сергей М. (2006-10-16 11:42:00) [33]

> Kolan © (16.10.06 11:13) [99]

> Сделал по статье - акуратно

suspend твой в доп.потоке - тоже по статье ?)

Kolan (2006-10-16 11:13:00) [34]

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

Ну не оправдан, знаю что до конца не разобрался. Сделал по статье - акуратно. Работатет не подводит. Уже сделано, зачем менять?

Сергей М. (2006-10-16 11:06:00) [35]

> Kolan © (16.10.06 10:56) [97]

> Смешно конечно звучит: Чтобы форма не висла

Ты даже не представляешь, насколько это смешно)..

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

Kolan (2006-10-16 10:56:00) [36]

> Чем в этом случае оправдан выбор асинхронного режима ?

Смешно конечно звучит: Чтобы форма не висла... Работает пока и бог с ним. Тут бы это передеалть.. А с портом видно будет. Порт кстати пока не подводил...

Сергей М. (2006-10-16 10:54:00) [37]

> Kolan © (16.10.06 10:42) [93]

Цитата из той же статьи:

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

Твой доп.поток работает всего лишь с одним портом, а не с несколькими одновременно.

Чем в этом случае оправдан выбор асинхронного режима ?

Kolan (2006-10-16 10:49:00) [38]

> Ни че не пойму с этими исключениями...

Как бы так и продолжаю не понимать :)

Думаю сделаю так:
В еще одном потоке "обработки" завиду очередь пакетов. При получении пакета буду туда добавлять и будить его. Поток будет просыпаться выбирать пкеты и обрабатывать. Ну как?

Дальше обработав пакет(массив) он будет создавать объект пакет.
И отдавать на обработку гл потоку.Опять же как тут быть? Опять Synchronize(DoSmth)? Получится тоже самое... Только теперь другой поток будет ждать пока DoSmth не завершится..

Kolan (2006-10-16 10:42:00) [39]

>
> Предлагаешь выключить компьютер? :-)
>
> Поставь Sleep(50), и не мучайся...
>

Все же усыплять - красивше :) У меня тогда душа спокойна :)...

Kolan (2006-10-16 10:42:00) [40]

> Тогда зачем асинхронный режим задействован ?

ХЗ. Дела я все это по статье:
http://morgeyz.elayne.ru/comlpt.htm

В конце статьи:

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

Прям про мою задачу :) Вот я и выделил...

Страницы: < 1 2 3 4 5 6 7 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »