Как затормозить основной поток?

← →
ChainikDenis © (2007-01-21 15:20) [0]

Точнее не просто тупо затормозить, а дать отработать дополнительному.

Отсылаю команду idUDPServer1.SendBuffer(...) и соотвественно должен прийти ответ, который сгенерирует событие idUDPServerRead.
idUDPServer1.TheadedEvent = true, т.е. событие будет отработанно в параллельном потоке.

Если обработка события будет слишком длительная, то я успею за это время еще раз отправить и получить ответ. Не хорошо. Хочу сделать гарантированную паузу, примерно 5 мс после отправки. Что бы пришедший ответ был обработан.

Собственно вопрос.

Если я после idUDPServer1.SendBuffer(...); воткну Sleep(5) это притормозит только основной поток или поток чтения idUDPServer1 тоже?

← →
tesseract © (2007-01-21 15:29) [1]

> Если я после idUDPServer1.SendBuffer(...); воткну Sleep(5)
> это притормозит только основной поток или поток чтения
> idUDPServer1 тоже?

А WaitForSingle(multiple)objects не лучше будет? Просто подожи пока поток отработает и всё.

← →
властелин колхоза (2007-01-21 15:30) [2]

Sleep. Suspends the execution of the current thread for at least the specified interval.

Только Sleep(5) -- это пять МИЛЛИсекунд. ;-)

← →
sniknik © (2007-01-21 15:56) [3]

ага, а потом начнутся вопросы - "вот я заблокировал, а юзер в это время ничего делать не может/форма не обновляется..." и т.д. начнутся вставки ProcessMessages... и по кругу.

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

← →
Макс Черных © (2007-01-21 18:35) [4]

> "вот я заблокировал, а юзер в это время ничего делать не
> может/форма не обновляется..."

На то есть MsgWaitForMultipleObjectsEx

← →
Kolan © (2007-01-21 18:46) [5]

Нафиг доп поток если его будет ждать основной?
Если так хочшь то и делай все в осн. потоке&#133

← →
sniknik © (2007-01-21 19:24) [6]

Макс Черных © (21.01.07 18:35) [4]
> На то есть MsgWaitForMultipleObjectsEx
если ты откроешь события для действий юзера, то что ему помешает второй раз нажать отправку до получения ответа от первой посылки?

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

← →
Макс Черных © (2007-01-21 23:04) [7]

> > На то есть MsgWaitForMultipleObjectsEx
> если ты откроешь события для действий юзера, то что ему
> помешает второй раз нажать отправку до получения ответа
> от первой посылки?

Разве я утверждал, что MsgWaitForMultipleObjectsEx заменяет мозги программиста? И потом, можно получать только сообщения перерисовки и игнорировать любой ввод. Как говорится - дружно читаем MSDN.

← →
sniknik © (2007-01-22 00:19) [8]

> Разве я утверждал, что MsgWaitForMultipleObjectsEx заменяет мозги программиста?
нет, ты просто "рисанулся" умным словом, и сам ни капли не задумываясь.

а утверждал ты в [4], что с помощью MsgWaitForMultipleObjectsEx можно блокировать основной поток ожидая отработки дополнительного, и при этом и юзер чтото делать сможет и прорисовка останется... (вывод из -> ход обсуждения про блокировку, и пост ([4]) был на предупреждение о последствиях такой блокировки. логично)

а теперь ([7]) пытаешься свалить все на чужие мозги и на MSDN, ну и частично меняешь условия, действия юзера побоку, теперь только отрисовка... угу, а то что сам лажу "гонишь", это конечно мелочи.

давай на примере (с начинающего (автора) то не дождешься)
procedure TForm1.IdUDPServer1UDPRead(Sender: TObject; AData: TStream; ABinding: TIdSocketHandle); begin //ловим ответ end; procedure TForm1.Button1Click(Sender: TObject); begin IdUDPServer1.SendBuffer(...); //посылка, включен параметр выпонения в //паралельном потоке т.е. завершится команда сразу Sleep(20000); //ждем (т.е. блокируем основной) время побольше типа //большая посылка, чтобы не нажали второй раз до ответа end;
ну вот, что нужно написать вместо Sleep чтобы (понятно MsgWaitForMultipleObjectsEx ;), но как)
а - блокировать основной поток, но при этом ->
б - шла отрисовка интерфейса
в - юзер мог чтото делать (противоречие однако, это уже не блокировка будет, ну да ладно)
с - не мог послать второй раз до завершения первого
д - словить ответ

самый простой способ, не делать блокировок, а задизейблить кнопку в посылке и раздизейблить в ответе (+ в таймауте на всякий случай, это я забыл), мы конечно с гневом отвергаем... потому что... а не знаю почему, было предложено, но както не прижилось.

ну так? какие параметры или даже конструкции (с участием MsgWaitForMultipleObjectsEx естественно) нужно писать? просвети безмозглых.

← →
Смаг (2007-01-22 07:07) [9]

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

← →
sniknik © (2007-01-22 08:33) [10]

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

← →
Макс Черных © (2007-01-22 14:22) [11]

2 sniknik

> нет, ты просто "рисанулся" умным словом, и сам ни капли
> не задумываясь.

Дружок, а давай ка тв приведи примеры своих замечательных продуктов?
И сколько лет ты на этом сайте умные мысли пишешь. Что-ты сам написал?
И сравним с моим. Или что слабо? Гений блин. Надавали эмблем кому ни поподя. А потом удивляемся, что сайт в помойку превращается.

← →
pasha_golub © (2007-01-22 14:31) [12]

> 2Макс Черных
>
> 2 sniknik

Мальчики, не ссорьтесь!

2
> sniknik

Николай, действительно грубовато. Не по жынтельменски как-то.

← →
sniknik © (2007-01-22 14:37) [13]

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

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

← →
pasha_golub © (2007-01-22 15:30) [14]

> sniknik © (22.01.07 14:37) [13]

> > Николай, действительно грубовато. Не по жынтельменски
> как-то.
> не джентельмен и не пытаюсь им быть.

Я бы сказал: "пытаюсь им не быть" ;-)

← →
Макс Черных © (2007-01-22 15:47) [15]

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

Я тут прекратил просвещать безмозглых уже года три назад, наверно.
И аналогично поступают многие из, скажем так, ветеранов форума.
Намного правильнее подсказать, пути решения, навести на какае либо варианты и т.д. А человек должен сам выбирать то, что ему больше подходит. Кроме того, я не опровергал ни в чем ваш способ решения проблемы, а всего лишь указал, что есть и другие варианты. Почему это вызвало у вас припадок самомнения, я не понимаю.
А поскольку, прозвучало то, что я "гоню лажу", то я еще раз предлагаю подтвердить вам свою супер-пупер квалификацию конкретными примерами.
А если нет таковых, то и не надо не по делу учить других уму разуму.

← →
sniknik © (2007-01-22 16:54) [16]

> а всего лишь указал, что есть и другие варианты.
в том то дело, что это не вариант. совсем. так делать нельзя (по моей оценке это чтото вроде "шедевра" Архангельского с его обработкой потока в синхронизации. одного порядка.) и именно против этого было мое предупреждение в [3]-м. посте. этого и аналогов.

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

> то я еще раз предлагаю подтвердить вам свою супер-пупер квалификацию конкретными примерами.
"меряться" не буду. ни на каких условиях это ловля "на слабо".

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

так что я в свою очередь еще раз предлагаю, не "разглядывать личности" а вернутся к техническим аргументам. аргументированно на примере (если понадобится) доказать что я не прав, на этом конкретном случае. на том про что ветка, и на что были ответы.

← →
oldman (2007-01-22 17:16) [17]

> Kolan © (21.01.07 18:46) [5]
> Нафиг доп поток если его будет ждать основной?

+10

Может автор как-нибудь с приоритетами разберется?
Или от потоков откажется?
Или почитает хоть что-нибудь?

А то сабж такой забавный, хоть стой, хоть падай...
"Точнее не просто тупо затормозить, а дать отработать дополнительному." ваще прикольно...
ИМХО, потоки при любом приоритете выполняются НЕ ПО ОЧЕРЕДИ (то есть, первый завершился - второй пошел)
А как - НЕ СКАЖУ!!!

← →
ChainikDenis © (2007-01-22 18:24) [18]

Извините что не пояснил сразу в чем основная проблемма.
Суть вот в чем. Есть некоторое количество устройств. Часть из них работает про RS485, а часть - некие программы запущенные на компьютерах локальной сети. Назовем их регристраторы.

Устройства всегда только отвечают.
Т.е. в событии тамера который тикает каждые 50 мс производится следующее:

- считывается буфер RS485
- берется "следующее устройство".
Если оно работает по RS485, то через порт ему отправляются данные и выходим. А вот если оно работает по UDP то ему отправляется посылка и берется следующее устройство.
И так до тех пор пока не "возмем" устройство которое работает по RS485 или не превысим кол-во устройств.

Если ВСЕ устройства работают по UDP то каждые 50 мс я отправляю в сеть 256 широковещательных пакетов. Мало того что я же их и принимаю (т.к. они широковещательные), я еще и получаю ответы от устройств и их обрабатываю.

Хотел избавится от ситуации когда возможно совпадаение передачи и приема по UDP.

Сделал просто. Для каждого устройства ввел два параметра LastUDPSend и LastUDPRead.

И в конкретное усторойство передается пакет если ((LastUDPSend + 50) < GetTickCount) и ((LastUDPSend + 50) < GetTickCount).

Вроде все задышало веселее.

Спасибо.

← →
Макс Черных © (2007-01-22 20:32) [19]

2 sniknik ©

> в том то дело, что это не вариант. совсем. так делать нельзя

Ой да неужели. Ну посмотрите хотя-бы на TThead.WaitFor, я конечно понимаю, что исходники Delphi это что-то вроде "шедевра" Архангельского с его обработкой потока в синхронизации. одного порядка. Тем не менее, если вы чего-то не знаете или не умеете не надо утверждать, что оно неверно. Ну и чтобы не быть голословным - простой пример ожидания потока основной формой, которая тем не менее спокойно перерисовывается, скажем если по ней другим окном подвигать.
(Application.ProcessMessages - там использован для простоты понимания)
И я еще открою страшную тайну - подобный механизм очень часто используется и в Delphi и в самой Windows.

T := TTestThread.Create(True); T.FreeOnTerminate := false; H := T.Handle; T.Resume; repeat WaitResult := MsgWaitForMultipleObjects(1, H, False, INFINITE, QS_ALLINPUT); if WaitResult = WAIT_OBJECT_0 + 1 then begin PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE); if Msg.message = WM_PAINT then Application.ProcessMessages else PeekMessage(Msg, 0, 0, 0, PM_REMOVE) end; until WaitResult = WAIT_OBJECT_0;

← →
sniknik © (2007-01-22 23:13) [20]

угу, уже страшно.

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

> подобный механизм очень часто используется и в Delphi и в самой Windows.
ну насчет Windows не скажу, исходников нет, а в Delphi да есть, видел(поиск тоже есть) используется, 3 раза видел (1 в Classes базовый поток WaitFor, 2 в мидасовском сервере ScktMain потоках транспорта)... все в дополнительных потоках, и ни разу в основном... что в общем то логично, изврат это для основного.
причем чисто для ожидания только в WaitFor.

> Ой да неужели. Ну посмотрите хотя-бы на TThead.WaitFor
ты что серьезно не понимаешь, или не хочеш? основной от дополнительных не отличаешь, или просто ищешь где светлее?
говорим про основной! и только основной поток. мало ли что используется в других, там оно на своих местах...
конечно, т.к. основной/дополнительные это чисто условное деление, нет коренных различий, и теоретически все что используется в них можно применить для основного тоже, но это же логически неверно! (та же знаменитая синхронизация Архангельского разве у него код не работает? ошибки дает? но разве ж это правильно?)

==============
говорят - вы не умеете ездить на машине, больше первой скорости боитесь включать.
ответ - да что вы говорите! а смотрите как я бегом эту машину обгоняю... давайте мне права, и точка.
????
логичнее надо быть.

← →
Макс Черных © (2007-01-23 00:24) [21]

> а ведь еще надо ProcessMessages переделать

Собственно, ProcessMessages был приведен для простоты. Как общеизвестный, чтоли. Можете заменить на ProcessMessage(Msg).

> говорим про основной! и только основной поток.

А причем тут основной - не основной? В данном контексте важно создает/нет поток окна. И потом когда основной поток стоит в режиме ожидания сообщения, как думаете а как же это он ждет? Мышку опрашивает? или клаву? А ведь он стоит в таком-же Wait состоянии.
Т.е. программисту делать почти то же, что делает ОС никак нельзя? Ну-ну.

И потом, я не утверждаю, что использование Wait функций в основном потоке есть единственно верный способ. Я о том, что существуют разные способы решения подобных задач. Имеющие свои преймущества и недостатки. Вот тут потребны мозги, чтобы выбрать оптимальный путь, в каждом конкретном случае. Например, когда в приложении, скажем 200 кнопок, а ожидаемая задержка (трида или чего другого) невелика, то бывает гораздо логичнее тормознуть поток приведенным способом, чем городить блокировки на кучу взаимосвязанных кнопок. А если кнопки на Action сидят, то Тормознуть АctionList тоже возможно не всегда.
И к большому сожалению, у нас, обычно, "программисты" выучат что-то одно, а потом лепят это одно везде где нужно и не нужно. Абсолютно при этом не вникая в вопрос - оптимально ли нет это в данном конкретном случае. А потом читаем тут на форумах, что Delphi глючит, и работает медленно, и файл большой и то и се. И убедить их в том, что они не правы сложно, ибо код работает - работает. И мудрой (а не глупой) книжке соответствует. Но вот только люди, которые написали книжку, дали просто примеры, а не догму для слепого копирования.
Вот те, кто на форуме давно, наверняка помнят знаменитую историю про то, как чел не поставил точку где надо. И словил 2 балла на экзамене, хотя код был рабочим и давал верный результат. Но он был не отимален в данном конкретном случае. А чел не перебирал в голове варианты и не задумался над тем какой из них оптимален. А зря - надо было. И всем советую иногда над разными вариантами думать. А мне тут - "выверты программизма". Грустно это. И чем дальше тем хуже. А давным давно здесь, бывало, я утирал нос Юрию Зотову, а он утирал нос мне и другим. И в результате все мы говорили друг другу "Спасибо". За совет, за подсказку, за другой вариант решения задачи. И куда все делось? Вот поэтому многие и ушли с форума.

← →
sniknik © (2007-01-23 01:30) [22]

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

> За совет, за подсказку, за другой вариант решения задачи.
ты опять не понял. я не считаю это другим вариантом решения задачи, или новым для себя (спасибо говорить вроде не за что). наоборот предполагал, что чтото подобное "всплывет" насмотрелся тут же, и предупреждал именно против такого/подобного. и тут на тебе "нестандартное решение".

> И куда все делось? Вот поэтому многие и ушли с форума.
а может не по этому? может потому что вместо помощи в тематических конференциях большинство предпочитает потрепаться?

← →
Макс Черных © (2007-01-23 02:12) [23]

> именно выверт, логически неверный подход, блокировать организованный
> в VCL цикл выборки/обработки сообщений своим "WaitFor"

Мне, честно говоря, уже надоело объяснять, что это нормальный подход. Один из нескольких.

> потому тебе и приходится в своем коде "дырочку" для события
> отрисовки оставлять... а это уже неполноценная какаято блокировка.

Эта "дырочка" заложена самим смыслом существования MsgWait... функций.
И придумывали их в MS не дураки.

> ты опять не понял. я не считаю это другим вариантом решения
> задачи, или новым для себя

Собственно вам я ничего не советовал.

> и тут на тебе "нестандартное решение".

Ну вот опять про стандартные решения, каноны, шаблоны и т.д. А какое решение тут стандартное? Где этот стандарт? Кто его установил? Может есть где умная статья где все это сравнивается и анализируется? Вот мне, например, часто приходилось использовать очень нестандартные подходы к решению ряда задач, и некоторые неглупые люди тоже вопили - как так, не по канонам, в книжках нет такого. Однако практика показала, что прав был я, а не они. А ваш подход, извините, это подход программиста за штукобакс.
За сим бесполезный спор прекращаю, ибо вам я ничего доказывать не собираюсь, следуйте своим "стандартам", получайте свой штукобакс, вперед и с песней.

← →
Polevi © (2007-01-23 08:01) [24]

>sniknik © (23.01.07 01:30) [22]
послушай, чего ты уперся
пусть у меня несколько доп. потоков, мне надо завершить приложение - вполне нормальная ситуация взвести объект синхронизации который ждут доп. потоки в качестве флага завершения и подождать их завершения через WaitFor

Polevi © (23.01.07 08:01) [24]
в этом случае ничего против не имею. сам так жду при завершении программы (можно конечно потокам ставить "самоосвобождение" но так используемый FastMM не ловит их завершения/освобождения и ругается. с явным проще. всегда делаю так как проще, при аналогичном результате).

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

Робята! Давайте жить дружно!

Ей богу, мне уже надоело, комментировать глупости штукобаксников, но хочу обратить внимание на фразу из первоначального вопроса.

Хочу сделать гарантированную паузу, примерно 5 мс после отправки. Что бы пришедший ответ был обработан.

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

> оспаривается сам метод, в конкретном случае, логический
> подход

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

Так, ребят, прекращайте... Не хочу тереть, но чуствую что у вас идет на нарушение первого пункта правил...

Но по факту с высказыванием:

> "логически неверный подход, блокировать организованный в
> VCL цикл выборки/обработки сообщений своим "WaitFor", и
> считать это приемлемым решением? увольте"

не согласен...
VCL не безгрешна и полагаться на обратное как минимум ошибка...

> Посему спорить и не собираюсь.
ну да... именно поэтому из 26 постов треть твои. потому что не спорил...

> доводы "через задницу"
это единственное что "дошло"? :), вообщето главным был довод об отсутствии нужды в блокировке вообще, в этом случае, либо нужды в потоке. т.е. нужно ожидание делаешь без потоков, нужна асинхронность - значит не нужна блокировка... все просто.

p.s. кстати а какой аргументацией обладает зарплата? я получаю не штуку, хотя допускаю что у тебя (да и не только) она больше... ну и что? кое кому везет.

Rouse_ © (24.01.07 20:11) [28]
> не согласен...
> VCL не безгрешна и полагаться на обратное как минимум ошибка...
не согласен и ладно. но исправлять "грехи" VCL надо хотя бы с улучшениями. а не внося собственную "кривизну", либо переписывая кучу стандартного ради пустякового действия, аналога которому можно добиться всего парой строк.

> не согласен...
> VCL не безгрешна и полагаться на обратное как минимум ошибка.
> ..

Саня, знаешь, меня забавляет один момент. Вот почему то некоторые юзают, например, FastMM и другие подобные вещи которые заменяют/модифицируют "родные" механизмы заложенные в Delphi и VCL, но при этом считают, что блокировать организованный в VCL цикл выборки/обработки сообщений это крамола какая-то. Хотя такой подход - достаточно распространенная практика, (можно даже в MSDN посмотреть пример - Waiting in a Message Loop).

> хотя допускаю что у тебя (да и не только) она больше...

Ну, скажем так, гораздо больше :) Да и дело не в ней или в везении. "штукобакс" - темин такой, распространенный. Хотя, возможно, с ним я погорячился.

> вообщето главным был довод об отсутствии нужды в блокировке
> вообще, в этом случае, либо нужды в потоке.

Вроде я ни то ни то не утверждал. Человек спросил про задержку - ему дали навскидку несколько вариантов. Какой выбрать - его дело, пишет, то программу он сам. Выберет вариант, спросит если что будет непонятно.
Если кто-то не согласен с чем-то, ради бога - предлагайте свои варианты, может они будут более подходящими. Вот только не надо сыпать слова типа "Лажа" и т.п.

> sniknik © (22.01.07 00:19) [8]

Ты не прав. Совет был по делу. Если дело происходит в основном потоке, то действительно нужно использовать MsgWaitForMultipleObjects(Ex).

А твои всплески эмоций забрызгали всех окружающих.
Вдохни глубоко и успокойся.

> Ты не прав. Совет был по делу. Если дело происходит в основном потоке, то действительно нужно использовать
> MsgWaitForMultipleObjects(Ex).
если бы это был ответ на общий вопрос, либо на чтото другое (например позже приведенный пример ожидания завершения множества потоков для окончания работы программы) да никаких возражений, но...
см. [3] и [4] против чего возражения (а вовсе не против блокировок основного потока в принципе, в меня "обвиняют". вернее пытаются)
>> "вот я заблокировал, а юзер в это время ничего делать не
>> может/форма не обновляется..."
> На то есть MsgWaitForMultipleObjectsEx
т.е. функция может сделать блокировку но не блокировать действия юзера и отрисовку.
да функция пропускает события, есть возможность собственной обработки, но смотри что мы(вернее вы/он но не я) собираемся пропускать и самостоятельно обрабатывать - отрисовку и все действия юзера както нажатия на клавиши мыш, таскание за заголовок, кликанье, в общем - ВСЕ. практически все что обрабатывает VCL.
и среди всей этой массы надо будет выделить клик над "опасной кнопкой" которая сделает дубль посылку, или горячие клавиши ее же, извне выделить, в цикле сообщений, вне компонента кнопки (ее дизейблить почемуто посчитали неприличным), и не допустить.
понимаешь? или тоже нет? повторить практически все что уже есть в vcl (и назвать это блокировкой! хотя это будет скорее дубль обработка), чтобы повторить тот же дизейбл кнопки только "с обратной стороны", с уровня сообщений. все что ее не касается нужно будет обрабатывать/пропускать, иначе это будет несоответствие с той фразой на которую дан "совет".
если это нормально, то я балерина. и тогда и счас утверждаю нормально это сделать нельзя. вот именно в таком контексте, а с простейшим случаем в одно событие для примера (и дальнейшей посылкой в MSDN :).

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

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

ну если и счас меня "исковеркают" и неправильно поймут... то все, "умываю руки".

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

> sniknik © (25.01.07 03:15) [33]
>
> > Ты не прав. Совет был по делу. Если дело происходит в
> основном потоке, то действительно нужно использовать
> > MsgWaitForMultipleObjects(Ex).
> если бы это был ответ на общий вопрос, либо на чтото другое
> (например позже приведенный пример ожидания завершения множества
> потоков для окончания работы программы) да никаких возражений,
> но...
> см. [3] и [4] против чего возражения (а вовсе не против
> блокировок основного потока в принципе, в меня "обвиняют".
> вернее пытаются)
> >> "вот я заблокировал, а юзер в это время ничего делать
> не
> >> может/форма не обновляется..."
> > На то есть MsgWaitForMultipleObjectsEx
> т.е. функция может сделать блокировку но не блокировать
> действия юзера и отрисовку.
> да функция пропускает события, есть возможность собственной
> обработки, но смотри что мы(вернее вы/он но не я) собираемся
> пропускать и самостоятельно обрабатывать - отрисовку и все
> действия юзера както нажатия на клавиши мыш, таскание за
> заголовок, кликанье, в общем - ВСЕ. практически все что
> обрабатывает VCL.

Я не увидел всего этого в ответе.
Кода не было.
Ты это придумал, а потом еще и обвинил человека.
Мнительный ты стал. Устал? Так отдохни.
Если тебе уж так хотелось, то мог бы просто спокойно уточнить, а не устраивать нелицеприятную перепалку.

> Я не увидел всего этого в ответе.
ну, значит "обьясняльщик" из меня "никакой", т.к. твержу именно об этом на разные лады с самого начала.

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

> Ты это придумал, а потом еще и обвинил человека.
эээ... а как иначе? по несуществующему еше в природе коду, как узнать его поведение? только придумать (предпочел бы говорить "предполагать"), так, вот предположил, высказал, что как думаю ожидается ([3] пост) и именно на это получаю возражение, именно тем против чего предупреждал.
единственное про недоступность хендла потока "придумал" (или вернее до меня дошло), только когда писал ответ тебе. о чем тут же и сказал (т.е. раньше это у меня входило в "непредвиденные проблемы"). про само событие ответа от компонента предполагал но был не уверен (и до сих пор не уверен) к чему его отнести и будет ли оно блокировано.. (и проверять не буду... т.к. считаю подход в общем бессмысленным, а разрабатывать частности от него это просто впустую потраченное время)
и кстати человека я ни в чем не обвинял (безмозглым во всяком случае не называл) "обвинял" подход. на личности старался не переходить, в отличие от него.

ну да ладно, затянулось это все черезчур. хоть один, хоть както понял, и хватит, мне достачно.
p.s. на 2 последних фразы сознательно не отвечаю... потому как если отвечу, правду как думаю, это опять покажется грубостью и выльется в "спор с разглядыванием личности" по Жванецкому, вместо подыскивания аргументов по вопросу...
p.p.s. больше в этой ветке "не отмечаюсь".

Как затормозить основной поток? Найти похожие ветки