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

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

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

Зависание функции из модуля.

Profi © (2005-10-24 19:46:00)
Есть модуль, есть программа, в которую мы его подключаем. В модуле есть функция с циклом. При обработке большого количества данных программа, ясное дело зависает. Если бы цикл был в модуле формы, то не проблема, вставил Application.ProgressMessage в цикл и все. А как тут быть? Знаю, что можно сделать как-то, но не нашел как. Заранее спасибо.

Юрий Зотов (2005-10-25 07:18:00) [1]
> Германн © (25.10.05 02:16) [6]

Например, всегда, когда нужно чего-то дождаться (или что-то сделать) в фоновом режиме.

Например, надо дождаться завершения запущенной внешней программы. Простой вызов WaitForXXX приведет к зависанию интерфейса и ругани юзера, а тот же самый вызов из второго потока - не приведет.

TUser (2005-10-25 07:07:00) [2]
> Имхо, не видел до сих пор реальной необходимости их пользовать!

Вот тут у тебя одна из таких ситуаций - выполнение некоторой работы без зависания интерфейса.

Германн (2005-10-25 03:44:00) [3]
2 Джо © (25.10.05 03:22) [9]
Пока что все равно не согласен. Имхо.
Детально завтра, если понадобится. Сейчас иду спать, извини.

Джо (2005-10-25 03:22:00) [4]

> [8] Германн © (25.10.05 03:03)
> Но "одновременная обработка любых входящих запросов", имхо
> - невозможна. Всёравно придется их обработать последовательно,
> один за другим.

Имеем ситуацию.
В главном потоке имеется менеджер потоков, ожидающий, пока вызовут некий его метод, принимающий исходные данные для расчетов. Получив входные данные, менеджер запускает отдельный поток, выполняющий некую работу над этими данными. И так поступает с каждой новой приходящей порцией данных. Если не использовать потоки, вариантов 3:
1. Не получаем следующую порцию данных, не обработав предыдущий запрос. Недостатки - висим :(
2. Запускать для каждого задания отдельный процесс. Недостатки: Лишние накладные расходы, сложность синхронизации.
3. Делать свой механизм замораживания, переключение и возобновления работы между заданиями для создания иллюзии одновременной работы. Недостаток: велосипед.

Понятно, что слова "одновременная работа" в отношении потоков это абстракция. Но, абстракция полезная.

Германн (2005-10-25 03:03:00) [5]
2 Джо © (25.10.05 02:29) [7]

> Много применений, много.
Не имею возражений в целом.
Но "одновременная обработка любых входящих запросов", имхо - невозможна. Всёравно придется их обработать последовательно, один за другим.
"Или прослушивание портов" - не вдаваясь в тонкости, что это за порты, но, имхо, любые порты предполагают возможность асинхронной работы с ними. Так зачем же нужны потоки?

Джо (2005-10-25 02:29:00) [6]

> [6] Германн © (25.10.05 02:16)
> Не люблю потоки. Имхо, не видел до сих пор реальной необходимости
> их пользовать!

Например, одновременная обработка любых входящих запросов. Или "прослушивание" портов. Много применений, много.

Германн (2005-10-25 02:16:00) [7]
Не люблю потоки. Имхо, не видел до сих пор реальной необходимостиих пользовать!

Kolan (2005-10-25 00:17:00) [8]
Ну и второй способ - цикл сагнать в поток...

SamProf (2005-10-24 23:13:00) [9]
подключи в том модуле модуль forms и пиши там application.progressmesages;
Вот!

Игорь Шевченко (2005-10-24 22:52:00) [10]
Profi © (24.10.05 22:47) [2]

Application вообще-то глобальная переменная, зачем ее куда-то передавать ?

Profi (2005-10-24 22:47:00) [11]
Sergey Masloff (24.10.05 20:33) [1]
Модуль это UNIT? Тогда Application.ProcessMessages можно использовать спокойно

Да, но это значит, что надо в функцию передовать TApplication, а не хотелось бы!

Sergey Masloff (2005-10-24 20:33:00) [12]
Модуль это UNIT? Тогда Application.ProcessMessages можно использовать спокойно.

Если модуль это внешний бинарник - например DLL то нужно по другому.

Наверх

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