Например нужно организовать какой-то процесс (закачку из интернета, вычисления, поиск на диске и т.д.), при этом чтобы пользователь мог делать с нашим приложением что-либо. Раздвоить на несколько threads? Когда я писал видеозахват под win16, я ставил таймер на 1/8 секунды и все делал в функции обработки сообщений окна, куда они и приходили от таймера. Сам следил чтобы слишком долго не занимать систему.

А теперь я создаю класс, который не зависит от окна и не порожден от CObject. Свой в доску. Может зря?
Или все-таки можно без большой крови наладить взаимодействие эгоиста и MFC-шной армии бюрократов? Как надо это делать?

Да правильно это!
Я очень часто использую многопоточность!
Собственно что смущает?

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

T>Например нужно организовать какой-то процесс (закачку из интернета, вычисления, поиск на диске и т.д.), при этом чтобы пользователь мог делать с нашим приложением что-либо. Раздвоить на несколько threads? Когда я писал видеозахват под win16, я ставил таймер на 1/8 секунды и все делал в функции обработки сообщений окна, куда они и приходили от таймера. Сам следил чтобы слишком долго не занимать систему.

T>А теперь я создаю класс, который не зависит от окна и не порожден от CObject. Свой в доску. Может зря?
T>Или все-таки можно без большой крови наладить взаимодействие эгоиста и MFC-шной армии бюрократов? Как надо это делать?
Пожалуй проще породить класс от CWinThread, стандартный WM_TIMER не оконный класс не сможет обрабатывать, по крайней мере без субкласса какого-либо окна.
В принципе еще были "ядренные" таймеры, народ как-то делал, сам не пробовал ничего сказать не могу, но копать если не ошибаюсь надо в сторону CreateWaitableTimer. Но все же бы я лично пошел по пути наследование от CWinThread — надежнее это.

Hello!

А>Да правильно это!
А>Я очень часто использую многопоточность!
А>Собственно что смущает?

Cмущает необходимость взаимодействия порожденного процесса с родителем. Например надо выводить прогресс-индикатор, или как-то влиять на сам процесс. Как делается в общем случае? Должно же быть какое-то решение "по умолчанию"? Я новичок, мне бы совет на основе опыта. Это же распространенная задача, кто как решает?

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

WBR, Jack The Tormozz 271003

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

T>>Или все-таки можно без большой крови наладить взаимодействие эгоиста и MFC-шной армии бюрократов? Как надо это делать?

>> Но все же бы я лично пошел по пути наследование от CWinThread — надежнее это.

Тогда как взаимодействовать с окном? Сообщения выводить? Мож не стОит связываться? Если вычисления происходят внутри класса окна, оно не замерзнет? Система сможет по событию от мыша например еще раз вызвать мое окно? Или она будет ждать, когда будет обработано предыдущее сообщение?

WBR, Jack The Tormozz 271003

Здравствуйте, Аноним, Вы писали:

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

Я делал так. Создавал 2-й поток, который занимался обработкой данных, в качестве параметра передавал ему н-р указатель на класс диалого (который занимался отображением), у диалога был метод SetNewInfo,
этот метод добавлял новые данные к старым и посылал окну зарегистрированное сообщение с помощью PostMessage (только если предыдущее уже обработалось). Разумеется внутри метода использовались критические секции.

Здравствуйте, Аноним, Вы писали:

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

T>>>Или все-таки можно без большой крови наладить взаимодействие эгоиста и MFC-шной армии бюрократов? Как надо это делать?

>>> Но все же бы я лично пошел по пути наследование от CWinThread — надежнее это.

А>Тогда как взаимодействовать с окном? Сообщения выводить?
Взаитмодействовать с окном просто. Рабочий поток может просто посылать окну сообщения с помощью PostMessage.
Окно — может использовать для взаимодействия с рабочим потоком любый примитивы синхронизации — критические секции, события, семафоры, мьютексы... В зависимости от задачи.
А> Мож не стОит связываться?
Как мне кажется стоит. Хотя бы потому, что действительно качесвенное крупное приложение без многопоточности, по-моему сделать весьма сложно. А потом, время потраченное на освоение этой технологии с троицей окупится.
А> Если вычисления происходят внутри класса окна, оно не замерзнет?
А> Система сможет по событию от мыша например еще раз вызвать мое окно?
Замерзнет или см. ниже... )
А> Или она будет ждать, когда будет обработано предыдущее сообщение?
Именно — будет ждать, когда будет обработано предыдущее сообщение.
Вот поэтому твоя программа и замерзнет. Или тебе придётся разбивать алгоритм на малые куски, такого размера, что бы каждый кусок успевал обрабатываться за малое время. Потом вешать обработку такого куска на сообщение и помещать сообщение в очередь. Тогда сообщение по обработке очередного куска будет выбираться из очереди наравне с остальными сообщениями от мыши, клавиатуры и т.д. и программа будет продолжать реагировать на ввод пользователя. (Так и делалось в "сложных" приложениях под Win16).
Но! С практической точки зрения:
Возьми какой-нибудь относительно простой (но не тривиальный) алгоритм — ну хотя бы быструю сортировку или сортировку пузырьком. И разбей его так, что бы он выпонялся кусками. Тогда ты скорее всего увидишь, что:
— даже такой простой алгоритм значительно усложнится
— в результате это открывает возможность для кучи ошибок
— время на отладу резко возрастает
— надёжность кода падает
— время написания кода существенно увеличивается.
При многопоточной обработке:
Пишешь милый сердцу алгоритм почти так же легко — как и при написании его в стиле примера — то есть единственного и главного потока приложения, который вовсе не обязан заботиться о времени. Почти, потому, что в алгоритме имеет смысл предусмотреть возможность воздействия извне. Ну например — проверку сообытия, устанавливаемого, когда нужно завершить работу потока (например при завершении приложения). Однако такую проверку добавить гораздо проще (и она сама граздо проще) чем разбивка алгоритма на куски.

С Уважением, Андрей