ProcessMessages

← →
Eraser © (2006-11-01 15:24) [40]

> [37] YuRock © (01.11.06 15:17)

> (MainForm <> nil) and (MainForm.FormStyle = fsMDIForm)

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

← →
Eraser © (2006-11-01 15:25) [41]

> [39] Anatoly Podgoretsky © (01.11.06 15:23)

ну записи то там нет.

← →
Anatoly Podgoretsky © (2006-11-01 15:45) [42]

> Eraser (01.11.2006 15:24:40) [40]

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

← →
Anatoly Podgoretsky © (2006-11-01 15:47) [43]

> Eraser (01.11.2006 15:25:41) [41]

За то есть обращение к непринадлежащей тебе памяти. Между первой и второй
перерывчик не большой, во время которого второй поток уже уничтожил объект -
тут нужна критическая секция.

← →
YuRock © (2006-11-01 16:08) [44]

> Anatoly Podgoretsky © (01.11.06 15:47) [43]
> За то есть обращение
> к непринадлежащей тебе памяти. Между первой и второйперерывчик
> не большой, во время которого второй поток уже уничтожил
> объект -тут нужна критическая секция.

Блин, а голова программеру на что? Естественно, что пользоваться средствами, предоставленными Борландом, Майкрософтом и т.д. надо с умом! В этом случае, например, если используешь Application.ProcessMessages для выкрутки сообщений другого потока, надо знать, что желательно поток-то этот закрыть вообще нафиг, перед тем, как MainForm уничтожится (если она была вообще, конечно).

> Eraser © (01.11.06 15:24) [40]
> (MainForm.FormStyle = fsMDIForm)кстати подобных конструкций
> тоже стараюсь избегать.. в отличие от борланада ) хотя они
> если и поменяют работу компилятора - первые об этом узнают
> и перепишут код, а вот мне искать внезапно-появившиеся ошибки,
> при переходе на новую версию компилятора, в проекте на
> несколько десятков тысяч строк не хочется.

А с этим кодом что плохого? И при чем тут компилятор?

← →
Anatoly Podgoretsky © (2006-11-01 16:21) [45]

> YuRock (01.11.2006 16:08:44) [44]

> а голова программеру на что

А ты много такого видел, откуда тогда берутся AV?

← →
YuRock © (2006-11-01 16:26) [46]

> А ты много такого видел, откуда тогда берутся AV?

Нет, немного. Я видел только один случай, откуда берутся AV: когда обращаются к адресу памяти, доступа к которому нет.

← →
Anatoly Podgoretsky © (2006-11-01 16:51) [47]

> YuRock (01.11.2006 16:26:46) [46]

Например между первой и второй перерывчик небольшой.

← →
@!!ex © (2006-11-01 16:58) [48]

> YuRock © (01.11.06 16:26) [46]

Собственно никто не обещает, что при проверке второй части условия форма все еще будет не Nil. :))

← →
Anatoly Podgoretsky © (2006-11-01 17:04) [49]

> @!!ex (01.11.2006 16:58:48) [48]

Это первая проблема, а вторая никто не гарантирую, что не будут вычисляться
обе части выражения, первая безопасная, а по второй имеется счастье получить
AV по полной программе. Зависит от настроек компилятора.
Помню как кто то очень громко ругался на форумах :-)

← →
Игорь Шевченко © (2006-11-01 17:06) [50]

@!!ex © (01.11.06 16:58) [48]

> Собственно никто не обещает, что при проверке второй части
> условия форма все еще будет не Nil. :))

А собственно, посмотреть, при каких условиях она станет nil при проверке второго условия ?

← →
@!!ex © (2006-11-01 17:13) [51]

> Игорь Шевченко © (01.11.06 17:06) [50]

Если поток на некоторое время зависинит(ОС не гарантирует что всем потокам выделяется абсолютно одинаковое количество процессорного времени) и за это время форма будет уничтожена.

← →
Eraser © (2006-11-01 17:20) [52]

> [44] YuRock © (01.11.06 16:08)

> Блин, а голова программеру на что? Естественно, что пользоваться
> средствами, предоставленными Борландом, Майкрософтом и т.д.
> надо с умом!

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

← →
Игорь Шевченко © (2006-11-01 17:30) [53]

@!!ex © (01.11.06 17:13) [51]

Который из потоков ? :)

← →
@!!ex © (2006-11-01 17:46) [54]

Зависнет поток в котором выполняется
(MainForm <> nil) and (MainForm.FormStyle = fsMDIForm)

И за это время выполнится удаление MainForm

← →
Игорь Шевченко © (2006-11-01 17:49) [55]

@!!ex © (01.11.06 17:46) [54]

Особенно интересен момент удаления MainForm у Application. Я к чему говорю - на свете есть много моментов получения AV, просто у ряда из них частота возникновения невелика...

← →
@!!ex © (2006-11-01 17:51) [56]

Это придирка к примеру, не я его придумал. :)
ДА. Согласен. В таких слуаях AV ОЧЕНЬ редко, но всеже имеет место быть.
И это не есть гуд.
Такие AV хуже всего ловятся.
А когда прога падает раз в месяц и никто не может понять почему.... Программисты получают втыки.

← →
YuRock © (2006-11-01 17:59) [57]

> А когда прога падает раз в месяц и никто не может понять
> почему....

Мои проги не падают - я же говорил :)
Без перезапуска работают месяцами, пока винда не "попросит" перезагрузки из-за того, что юзер в какую-нибудь игру поиграл или еще что...

← →
Игорь Шевченко © (2006-11-01 18:01) [58]

@!!ex © (01.11.06 17:51) [56]

К сожалению, падающие раз в месяц проги обычно падают по иным причинам, нежели ProcessMessages, вызванный из другого потока.
Кроме того, программы обычно тестируют, как ни странно, выявляя массу ошибок и прочего непредсказуемого поведения.

Я бы не стал рекомендовать использование Application.ProcessMessages из другого потока только по одной причине - это неочевидный код. А любой неочевидный код должен найти свое законное место в корзине.

Других причин (вроде запрета вызова метода VCL-объекта из другого потока, ловля блох в последовательных проверках существования объекта и его теоретического уничтожения между проверками) я не вижу.

← →
YuRock © (2006-11-01 18:06) [59]

> Eraser © (01.11.06 17:20) [52]
> за такое "с умом" с работы попереть могут. я бы призадумался о компетенции такого работника.

Ок, я задумаюсь над своей компетенцией :)

> учти, что даже если тебе полностью понятно,
> как работает этот код в текущей версии VCL,

Ну, переходить на версию деолфей больше 6 я не собираюсь, и все мысли подчиненных на эту тему обрезаю накорню. Приводя примеры глюков компилятора D7 и выше, на которые я натыкался. Да, обойти их можно, но перелопачивать 70 мегабайт кода никто не будет.

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

А вот за такое с работы попереть могут :)

← →
YuRock © (2006-11-01 18:14) [60]

> @!!ex
> Eraser

Да, и почему вы решили, что я - за использование Application.ProcessMessages в других потоках? Это удобно, лишь если есть желание компилить проект на Кайликсе. Да и то - сомнительно.

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

И, естественно, ответ типа "Пока поверь мне на слово, а потом подростешь - поумнеешь" меня не полностью удовлетворил :)

← →
Eraser © (2006-11-01 18:19) [61]

> [59] YuRock © (01.11.06 18:06)

> Приводя примеры глюков компилятора D7 и выше, на которые
> я натыкался.

imho 7 - самая стабильная после 3 версия, хотя пользуюсь 10 )

> Ну, переходить на версию деолфей больше 6 я не собираюсь

если кода много переписывать прийдется, тоже не вижу смысла, лучше сразу на C# %-)

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

могут! если он не найдет ошибку, а если найдет, то сразу же перепишет как надо, при этом матеря аффтора того кода )

> Других причин (вроде запрета вызова метода VCL-объекта из
> другого потока, ловля блох в последовательных проверках
> существования объекта и его теоретического уничтожения между
> проверками) я не вижу.

а я не вижу гарантии, что в следующей версии VCL, туда не запуздырят какую-нибудь инструкцию, из-за которой данный код будет "падать". Ведь было же такое и не раз, не мне вам рассказывать.

← →
Leonid Troyanovsky © (2006-11-01 19:21) [62]

> YuRock © (01.11.06 18:14) [60]

> потом подростешь - поумнеешь" меня не полностью удовлетворил

Да, это так оно и есть. Подрастают, но не умнеют.
Отсюда и произрастает неудовлетворенность.

--
Regards, LVT.

← →
@!!ex © (2006-11-01 20:36) [63]

Помоему уже раз 10 на примерх показали, почему не стоит обращаться к незащищенным переменным и методам из разных потоков.

← →
Leonid Troyanovsky © (2006-11-01 21:00) [64]

> @!!ex © (01.11.06 20:36) [63]

> Помоему уже раз 10 на примерх показали,

Маловато будет.

--
Regards, LVT.

← →
YuRock © (2006-11-02 15:11) [65]

> @!!ex © (01.11.06 20:36) [63]
> Помоему уже раз 10 на примерх показали, почему не стоит
> обращаться к незащищенным переменным и методам из разных
> потоков.

Пока что был только 1 пример - мой, со 100% работающим кодом с ProcessMessages из другого потока.

Остальное - только рассуждения и предположения, не более того.

Если ошибаюсь, или я слепой - напиши номер поста с этими примерами. Желательно - 10-ти примеров. Касающихся сути вопроса, естественно. А почему так делать иногда нельзя - думаю, что знаю это не хуже тебя.

Подчеркиваю - иногда!
Ты ведь пользуешься переменной IsMultiThread в резных потоках, и не засовываешь обращения в CS? Или DecimalSeparator? И таких примеров - действительно миллион. Так зачем чушь нести? И какое это все вообще имеет отношение к теме вопроса?

← →
Сергей М. © (2006-11-02 15:29) [66]

> YuRock © (02.11.06 15:11) [65]

Если ты, дружок ситный, завел всю эту безапелляционную трындельню, то ты, дружок ситный, должен при этом понимать, что объект Application, чей метод ProcessMessages вызывается в потоке X, должен быть создан не иначе как в контексте потока Х.

В противном случает цена твоей трындельне - три копейки в базарный день)

← →
YuRock © (2006-11-02 15:37) [67]

> Сергей М. © (02.11.06 15:29) [66]
> > YuRock © (02.11.06 15:11) [65]Если ты, дружок ситный,
> завел всю эту безапелляционную трындельню, то ты, дружок
> ситный, должен при этом понимать, что объект Application,
> чей метод ProcessMessages вызывается в потоке X, должен
> быть создан не иначе как в контексте потока Х.В противном
> случает цена твоей трындельне - три копейки в базарный день)

А, что, по твоему есть разница, в каком потоке выделять память? :)))))))))))))

← →
Сергей М. © (2006-11-02 15:41) [68]

> YuRock © (02.11.06 15:37) [67]

Причем здесь выделение, дружок ?

Речь идет об обращении к одному и тому же (уже существующему !) объекту TApplication в контексте более чем одного потока процесса

> Сергей М. © (02.11.06 15:41) [68]
> Речь идет об обращении к одному и тому же (уже
> существующему !) объекту TApplication в контексте более
> чем одного потока процесса

Т.е. если объект создан в потоке X, то в потоке Y его использовать нельзя. Так?

> если объект создан в потоке X, то в потоке Y его использовать
> нельзя. Так?

Репу почесав - можно.
И оную же почесав - нельзя.
Репа программеру дана не только для пожирания чего-то там)

> Eraser © (02.11.06 16:13) [70]
> его нельзя использовать в обоих потоках одновременно.

> Сергей М. © (02.11.06 16:13) [71]
> Репу почесав - можно.И оную же почесав - нельзя.

Ребята, зачем вы чушь несете? Вас же вообще ничего незнающие люди читают и верят!!!

Вы пользуетесь компонентами типа Indy, IBX... Да просто классом TThread? Если да - то вы ОБЯЗАТЕЛЬНО ОДНОВРЕМЕННО используете один объект в разных потоках!

Application.ProcessMessages в дополнительном потоке - всё равно что трусы на голове - носить можно, но глупо и чревато менингитом с летальным исходом.

> YuRock © (02.11.06 16:30) [72]

> Ребята, зачем вы чушь несете?

Затем чтобы никому не было повадно использовать сабж в своих многопоточных разработках при использовании VCL.

Get/Peek/WaitMessage упразднены уже, а ?

> [72] YuRock © (02.11.06 16:30)

> Если да - то вы ОБЯЗАТЕЛЬНО ОДНОВРЕМЕННО используете один
> объект в разных потоках!

не используем.

> не используем.

Мда? А никогда не приходилось в TThread.Execute делать такой цикл:

while not Terminated do begin //... end;

а при закрытии приложения, чтобы корректно завершить работу этого потока вызвать, например, Thead1.Terminate или Thead1.Free, который тоже вызовет Terminate?

Если приходилось (а такого не могло не случиться :) ), то да, используете... Переменную класса TThread.FTerminated присваиваете в одном потоке, а используете - в другом... Безо всяких CS. И это - общепринятый метод - когда можно - использовать такое. Одновременно :)

> YuRock © (02.11.06 16:59) [76]
>
> Переменную класса TThread.FTerminated
> присваиваете в одном потоке, а используете - в другом...
> Безо всяких CS. И это - общепринятый метод - когда можно
> - использовать такое. Одновременно :)
>

Все дело в SizeOf(FTerminated).

скучно...

> Все дело в SizeOf(FTerminated).

Не только. TThread.FSynchronizeException еще очень большое значение имеет в этом контексте...

> YuRock © (02.11.06 17:09) [79]
>
>
> Не только. TThread.FSynchronizeException еще очень большое
> значение имеет в этом контексте...

И какое же значение?

ProcessMessages Найти похожие ветки