Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, IWannaTalk, Вы писали:

А>>>>>Вместо того чтоб гадать на кофейной гуще, сделали бы лучше обработку ошибки от PostThreadMessage.
IWT>>>>обработка PostThreadMessage есть, мне интересна статистика нагдруженности, которую я хочу писать в лог.
А>>>InterlockedIncrement(&pending_messages) перед PostThreadMessage и InterlockedDecrement(&pending_messages) после GetMessage — лучшее средство от геморроя.

IWT>>не так все просто...

ГВ>А точнее?

ГВ>Отслеживать загрузку по длине очереди, ИМХО, не самая хорошая затея. Она либо стремится уйти в нуль даже после всплесков нагрузки, тогда, по крайней мере, в этом аспекте проблем нет, либо в каких-то ситуациях начинает неуправляемо расти (скажем, зацикливание) и скорее всего, здесь хватит простой диагностики ошибки PostThreadMessage.

ГВ>Сугубо архитектурно вторую проблему можно решить протоколом обмена данными между потоками. Например, если у нас есть два потока A и B, то A шлёт сообщения B, а B шлёт в сторону A подтверждения их обработки. Пока очередное подтверждение от B не получено, A не отправляет B сообщений. Тихо, мирно, никто никого не перегрузит.

допустим, 1000 потоков шлют меседжи ОДНОМУ другому. и + некоторые потоки воопще из элиен компонентов. вот в чем сложность! а мне кажеться, что иногда бывает оверфлов очереди, потому что бывает странное поведение приложения. ошибку от PostThreadMessage я могу обработать, но если этот метод вызываеться элиеном?
если б у меныя был другой способ, я бы не постил ненужный топ.

ТО: x64
спс, щас попробую