Пишу на работе(от нечего делать ) многопоточный пингер на VC++ MFC. И столнулся с небольшой проблемой. В общем идея такова:
Есть CTreeCtrl - в него предпологается добавлять найденые(живые) тазики. По нажатию "Скан" запускается AfxBeginThread'oм сканирующий поток, который в цикле запускает пинг для каждой тачки(диапазон айпи адресов). Каждый пинг тоже в отдельном потоке. И эти потоки массово устремляются в работу. Как только какой-то из потоков понимает что тачка жива шлёт PostMessage(кстати почему SendMessage не работает?) главному окну(где сидит CTreeCtrl) на добавление нового элемента к дереву. Вроде всё работает,но... Если во время сканирования взятся за окошко мышкой и потаскать его(например), то сообщения пришедшие в это время не обработаются и соответсвенно мы не получим полную картину. Есть ли у этой проблемы какое-нибудь элегантное решение?

Есть, использовать вариант с буферизацией полученных данных. Пусть за добавление отвечает другой поток и пусть будет класс по типу стека. Потоки пинги при нахождении компа, вписывают данные с класс стек и ставят флаг, что есть данные, а поток ожидающий появления данных в стеке их оттуда берет и пихает в treeview. Хотя здесь тож есть подводные камни. Зачем тебе понадобилось делать все на потоках?

Просто я использую класс CPing (на исходниках.ру скачал), который достаточно тормознутый. Он неживые тачки около 10 секунд пингует, в итоге получится если без потоков 254*10=42мин . А свой пинг не могу написать - силёнок мало. Полагаю вот здесь лажа:

Вот gethostbyaddr и тормозит.

А по поводу

Так, блин, ещё потоки добавляются. Я придумал по другому. Берём массив чисел. При запуске сканирования его обнуляем. И получая сообщение от потока перекидываем соответсвующий(номер элемента в lParam сообщения) элемент в единицу. А поток PostMessage в цикле шлёт, постоянно проверяя элемент массива на неноль (тогда цикл вместе с потоком прекращается). В итоге имеем: если окно по каким-то причинам не принимает сообщения, то потоки будут просто слать сообщения ... до победы. Единственный минус - во время таскания окошка естественно в него ничего не добавляется, но если отпустить то сразу всё что ждало прорисовывается.

И будет тормозить, сама функция такая.

А как точнее обрабатывается прием сообщений? Чем?
А нельзя ли обойтись без них?
В общем идея такая. потоки:
1) Обработка собыйти пользователя
2) диспетчерезатор пингов
3) сами пинги

Пусть есть список IP. И какой-то IPC, на которой мы вешем ожидать дисптчерезатор... Как только прошел пиг, добавляем что надо (или меняем что нрадо) в список и запускаем диспетчерезатор. Он заполняет UI обекты, а уж за их отрисовку отвечает первый поток

Ray Adams

Да но если взять например стандартный пинг.ехе то он сразу говорит есть тачка или нет. Получается он этой функцией не пользуется?
nickyoz

Перегрузил PreTranslateMessage и получаю сообщения первым, обрабатываю и шлю его дальше. Т.е. сообщения обрабатывает окно, в которое и надо добавлять найденные компы.
А по поводу твоего способа: я не совсем понял. Получается каждый поток пинга будет запускать диспетчеризатор (язык можно сломать )? Т.е. он будет добавлять на окно информацию (ну типа указатель_на_класс_окна->класс_CTreeCtrl.AddItem(xxx) ) ? А кто будет пускать пинги на работу? Если это сделать 1) потоком, то во время отправки окно будет "висеть", а идеале отправка может затянутся. Или я не правильно понял ?

Нет, не пользуется


А вообще, google в руки и вперед. В нете миллион примеров создания пинга

Добавлено спустя 7 минут, 2 секунды:

Не правильно понял. Вообщето то , что я предложил может повлечь кучу других багов, так как придется заботится о синхронизации такой работы. Лучше всего покопай, как делать ping самому!

Ray Adams
Да нее. Под выражением "отправка может затянутся" я имел ввиду отправку в цикле потоков-пингов. Т.е. имея идеальный пинг эта проблема всё равно остаётся. Выходит так что я щас пытаюсь просто разобратся с многопоточностью и GUI'ем, а качество "моего" пинга это уже другой вопрос - уже накачал кучу исходников .

как ты его отсылаешь. Хотя если честно, я под форточку ДАВНО не работал

Нет. Не правильно
Описываю точнее
1) GUI-thread - один поток, отвечает за пользоателские события, отрисовку окна и так далее.
2) Control-thread - то же один в системе.
Пусть у нас есть очередь. В неё будем добавлять то унформация, которую необходима вывести.
Пусть у нас есть IPC (по моему семаформаи зовется), назовем его ipc_wait. Мы будем на нем ждать. Когда у нас кто-то что-то добавил, мы заканчиваем ожидание(см. ниже), проверяем что очередь не используется, захватываем её, читаем добавленную информаци, делаем необходимые изменения в GUI-обектах (окнах, разных там элементов окон и так далее, что ты там использыешь для общения с юером. При этом надо не забыть чтоб это было синхранизовано с GUI-thread), удаляем информацию из очереди, которую вывели, и вызываем перерисовку окна.
3) ping-threads. Сколько душе угодно... Выполняет пинг. Прверяет что очередь ни кто не сипользует. захватывает очередь. Добалвяем нужную информацию. Освобождаем очеред. Увеличиваем семофор ipc_wait на единицу, при этом разблокирем control-thread.
ВСЁ

mein Вот nickyoz лучше обьяснил , что я хотел сказать по поводу потоков и записи с буферизацией.

nickyoz, Ray Adams Ну всё я понял что я ничерта не знаю и мне ещё рано, по ходу, этим заниматся. Попытаюсь найти время и почитать что-нибудь на эту тему.

mein
Ничего страшного. Учись.... Вот помню как я впервый писал многопточность.. мммм... столько напортачил