Появилась необходимость сделать в приложении процесс, максимально при выполнении не зависящий и не тормозящийся от основного процесса, при этом он сам не должен тормозить основной процесс. Попытка выделить его в отделиный Thread к успеху не привела — все равно допустим при минимизации основного окна выполнение процесса тормозилось.
Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.
Прочитав про технологию COM я понял что это как раз решение моей проблемы.
Подскажите, правильно ли я понял — что мне надо просто создать ActivX DLL — которая как раз в своей работе создаст независимый поток в моем приложении, который как мне и надо, не юудет тормозить основной поток? Или же мне надо создать ActivX EXE- фаил? Необходимости запускать отдельно данный процесс нет, так что вроде как ActivX DLL подходит больше.

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

>[..]
Вот мои мысли по этому вопросу:

1. Если что-то будет работать параллельно с основным приложением, оно по-любому будет загружать систему => основному приложению достанется меньше процессорного времени — а это и есть торможение
2. Вариантов всего два — это либо потоки в одном процессе, либо потоки в разных процессах. И ActiveX/COM этого положения вещей никак не изменяет, поэтому ИМХО это лишнее.
3. Процесс по определению тяжелее потока, ибо требует больше системных ресурсов.
4. Попробуйте поиграться с приоритетами потоков, может быть это то, что вам надо.

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

R>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.

Если делать полностью асинхронный обмен данными, то, может, лучше будет разделяемая память? Накладных расходов при этом минимум (практически все реализуется аппаратно) в отличе от COM с его маршаллингом.
А ActiveX DLL отдельный поток сама по себе создавать не будет, это надо еще там написать. В результате опять получится многопоточное приложение...

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

R>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.

Можно еще пайпы использовать

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

R>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.

в чем эта проблема заключается?

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

R>Появилась необходимость сделать в приложении процесс, максимально при выполнении не зависящий и не тормозящийся от основного процесса, при этом он сам не должен тормозить основной процесс.

Сначала думал предложить концепцию доменов в .NET, но не знаю как сделать, чтобы не тормозить основной процесс. В общем RTFM, может быть там что-нибудь есть на эту тему.

R>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.

Обмен данными — проще простого. Remoting.

Все это, конечно, если ты используешь .NET.

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

R>Появилась необходимость сделать в приложении процесс, максимально при выполнении не зависящий и не тормозящийся от основного процесса, при этом он сам не должен тормозить основной процесс. Попытка выделить его в отделиный Thread к успеху не привела — все равно допустим при минимизации основного окна выполнение процесса тормозилось.
в чем проявляеться "торможение"?
явно что-то напутал, минимизация главного окна не должна влиять на "вычислительный" поток, Создай обычный Worker Thread, если используеш мфс, и посмотри тормозиться он или нет

R>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.
R>Прочитав про технологию COM я понял что это как раз решение моей проблемы.
R>Подскажите, правильно ли я понял — что мне надо просто создать ActivX DLL — которая как раз в своей работе создаст независимый поток в моем приложении,
ты уже пробовал создават отдельный поток, не вышло, а чем поток созданый в активХ будет лучше?

R>который как мне и надо, не юудет тормозить основной поток?
еще прочитай про потоковые модели в комах и про апартменты, обьясняь это в форуме слишком долго.

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

R>Прочитав про технологию COM я понял что это как раз решение моей проблемы.
Ты ошибаешься.

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

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

R>>Тогда была сделана попытка просто выделить этот процесс в отдельный EXE-фаил . Тут вышла другая проблема — обмен данными с приложением.

FN>Если делать полностью асинхронный обмен данными, то, может, лучше будет разделяемая память? Накладных расходов при этом минимум (практически все реализуется аппаратно) в отличе от COM с его маршаллингом.
FN>А ActiveX DLL отдельный поток сама по себе создавать не будет, это надо еще там написать. В результате опять получится многопоточное приложение...

Это через так называемый шареный сегмент dll-ки? Я делал, но с синхронизацией проблемы все равно.

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

C>в чем проявляеться "торможение"?
C>явно что-то напутал, минимизация главного окна не должна влиять на "вычислительный" поток, Создай обычный Worker Thread, если используеш мфс, и посмотри тормозиться он или нет

Ничего он не напутал.
Минимизация окна приложения с NORMAL_PRIORITY_CLASS понизит ему приоритет выполнения (соотвественно и всем его потокам), так уж в Windows устроен шедулер.
Хотя по самой постановке задачи фиг поймешь, что человеку надо, только догадки остаются.
Догадки у меня такия — взаимодействие только асинхронное (не блокирутеся ни тот ни другой), т.е. роем в сторону обмена сообщениями, очередей сообщений, active objects...
Если на C++ — то доктор прописал ACE, чтобы велосипедов не изобретать.

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

D>Это через так называемый шареный сегмент dll-ки? Я делал, но с синхронизацией проблемы все равно.
Можно FileMapping или именовынные каналы (Named Pipes).
Синхронизация посредством их же или семафоров (Mutex).