Тоже безопасно... Иногда не без удовольствием пользуюсь им :)

Василий 2Ерунда. Выделил в одном потоке, переслал второму, тот получил и удалилА есть гарантия, что адресат это сообщение в результате получит, обработает и удалит то, что требуется удалить? Когда SendMessage, там понятно, а PostMessage не дожидается ответа, пуляет и уходит.

Василий 2,
И что возвращает функция PostMessage?

Василий 2,

Насчет PostMessage: она не дожидается, когда адресат получит сообщение, поэтому очищать данные, например буфер передаваемой строки - ошибка. в SendMessage именно так и работаем: передаем в качестве параметра указатель на строку или структуру, а после выполнения функции - удаляем, если требуется. PostMessage либо доставит в итоге ссылку на удаленные данные, либо, если обеспечить их сохранность, понадеясь на то, что их удалит адресат, то нет гарантии, что тот их вообще получит, и данные не повиснут в памяти мертвым грузом. Поскольку PostMessage, само собой, отработает быстрее всего, не заставляя поток ждать ответа от другого потока, то у меня была идея собрать стэк данных, данные создаются там, и ссылка на них передается между потоками. Но тут выходит, что для обработки стека требуются его блокировки, опять же, и получается, что меняю шило на мыло, и я просто
воспользовался sendmessage. Правда задача у меня гораздо проще: обмен данных исполняющего запрос потока с главным потоком приложения, чтобы то отрисовало статус запроса. К тому же, после того, как захотелось еще, чтобы юзер мог и остановить процесс, то выяснилось, что никуда не деться от SendMessage в принципе: и теперь я отправляю основному потоку приложения сообщение, он обрабатывает его, рисуя юзеру статус, при этом получает от юзера, возможно, нажатие кнопки "не хочу ждать, пусть всё прекратится, остановите это!!", и возвращаю результат передавшему потоку. В итоге, конечно, если основной поток зависнет, или в основном потоке запустят другой запрос, то все мои потоки встанут, конечно.

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

Прошу поправить, если я где-то в своих утверждениях ошибся.

DarkMasterV.Borzovпропущено...
А есть гарантия, что адресат это сообщение в результате получит, обработает и удалит то, что требуется удалить? Когда SendMessage, там понятно, а PostMessage не дожидается ответа, пуляет и уходит.

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

YuRock...
Ну понятно :)


Ой, точно! :)

чччДV.Borzov...в SendMessage именно так и работаем: передаем в качестве параметра указатель на строку или структуру, а после выполнения функции - удаляем, если требуется...

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