Russian Qt Forum

Как с Qt приостановить процесс какой-нибудь программы по имени процесса ?

если под никсами то зовешь ps ax | grep process_name, парсишь его вывод, берешь оттуда pid и зовешь kill -9 pid
Это если наверняка надо. Если же просто послать сигнал завершения (который не обязательно завершит процесс), то killall process_name

Я слышал что Qt кроссплатформенна....


Завершать не надо, надо приостановить, чтобы потом можно было продолжить с прерванного места

Qt конечно кроссплатформенна, но подобные вещи являются уж совсем не кроссовыми и возможными не на всех платформах (на винде насколько я помню это недокументированная функция ntdll).

Процесс имеет хотя бы 1 нитку (thread), как ее остановить? Или даже: как процесс может остановить одну из своих же ниток? Да никак, можно только послать событие, выставить флаг и.т.п. полагая что код, выполняющийся в нитке, это "поймет" и перейдет напр. в ожидание на семафоре. Но если нитка этого не делает - заставить ее нечем. То же и с процессом.

в никсах - черт его знает, а в винде:

• Process32First, перечисляем все процессы, находим по имени процесса - PID
• Thread32First, перечисляем все потоки, определяем относятся-ли они к нашему процессу
• Открываем поочередно каждый из потоков, с правами, помимо всего прочего, на THREAD_SUSPEND_RESUME
• А далее на вкус SuspendThread или КуыгьуThread, на выбор

По идее должно работать.

Это, опять же, только "порекомендует" потоку остановиться. Но не заставит. Реакцию на такое предложение поток определит сам для себя. Никто не заставить поток встать. Гарантированно его можно только убить. Все остальное будет зависит от самого потока, как он написан, в какой момент ему придет это "предложение" подождать и т.д.

чтоб остановить поток/процесс, нужно сохранить его контекст, и и изъять его из списка обрабатываемых контекстов.
в никсах есть АПИ уровня ядра, но его невозможно использовать из прикладного уровня, сами понимаете. не вкурсе если в вендах такое есть, но думаю что нет. ибо не должно такого быть. если же есть надобность в подобном, это однозначно говорит об ошибке проектирования.

Это далеко не предложение :) Если удастся открыть поток с нужными правами и функция SuspendThread вернет положительный результат - поток остановлен, факт.

Если удастся и если вернет это гарантированный результат? Я весь поток могу написать одной большой критической секцией. Не встанет он. А автор темы хочет чужие потоки тормозить. При этом не зная кто они и зачем нужны. Если я напишу прогу которая, например, реализует четыре потока( у меня четыре ядра) каждому потоку я скажу что он может выполнятся только на конкретном ядре, три потока будут считать а четвертый для синхронизации прочей служебной фигни. Что будет если какой-нибудь негодяй остановит поток для синхронизации??? Правильно или "мы все умрем" или фиг ему а не приостановка потока.

Ладно, расширим наш багаж знаний, читаем MSDN
Оно конечно, "нет преград энтузиастам", но мне кажется - связываться с таким мутным делом не резон, скорее всего не остановим, а покалечим. Ну и кросс-платформенностью там и не пахнет. Напр. в Posix такого точно нет

Павел_F, если поток программы выполняющий приостановку потоков выполняется, то в любом случае, в твоем примере не все потоки работают ;) Че тут, пробовать надо, а не рассуждать о страшных последствиях :) К тому же ситуация частная, и такое встретить в реальной жизни - шанс маленький. Способ не идеален, я не спорю, но вполне рабочий.

Igors, в дедлок оно попадет при условии что:
а) используются объекты синхронизации (почти всегда часто)
б) мы останавливаем 1 поток с объектом синхронизации (тоже вполне может быть, и что?)

Разумеется остальные потоки будут ждать приостановленного нами. Но в конце концов мы же его запустим, вероятно не плохо бы при этом соблюсти порядок стэка для ResumeThread.

ЗЫ
Помимо критики, уважаемые, могут предлагать способы получше, либо меры по улучшению данного решения ;)

ЗЗЫ
На счет кроссплатформенности, внимательно выше:

kill -STOP <pid>

продолжить -

kill -CONT <pid>

Попробовать-то не вредно, только вот заказчику я бы такую фичу не обещал - потому как не знаю что мне ему ответить если он спросит "Я за это заплатил, а оно вылетает, а на той платформе вообще не работает. Исправляйте как хотите, это Ваши проблемы".

Исходный вопрос надо понимать "есть ли легальная, кросс-платформенная возможность остановить процесс средствами Qt?" (пусть автор меня поправит если не так). Нормальный ответ на этот вопрос: нет, такой возможности нет. А хотите делать используя нативные средства ОС (крутизну  показать) - дело Ваше, но это может дорого Вам обойтись.

[floodMode]

В Qt много чего нет, прослезитесь, но посмотрите исходники, того же самого qextSerialPort многострадального. Работы с последовательными портами в Qt тоже нет, и posix порт там реализован далеко не идеально, но когда кого это останавливало?

Не хотим, но есть такое слово как "надо", и против "надо", извините, не попрешь.

[/floodMode]

Заканчиваю флуд и более на подобные провокации не откликаюсь. Кто с чем не согласен, в личку, будьте добры, там мне не кому будет "крутизну показать".
Спасибо за внимание, всегда Ваш, возмущенный sne. :)

Я вот чего подумал - а ведь сам ОС постоянно передает управление от одной нитки к другой. Если напр. я в нитке уйду в глухие вычисления, то ОС ведь не умрет, даже на 1 процессоре. Хммм... и как он это делает? Более того, он делает это довольно быстро, напр. с тем же 1 процессором 8 ниток не будут сильно медленнее чем 4.

шедулеры и вытесняющая многозадачность великая вещь не правда ли?)

Ну эти слова я тоже слышал  :) Можно предположить что OS получает управление "по прерыванию от таймера" (как это называлось раньше). Ладно, с учетом приоритетов посчитал кому надо дать процессор(ы) а кого и тормознуть. Ну а дальше-то что? Все равно надо передать управление от нитки к нитке, а для этого переключить стек, восстановить регистры и.т.п. И все это с успехом делается - интересно/полезно было бы узнать как, пусть в общих чертах.

На платформе x86 это делается аппаратно (со времен 80286). Так называемый - защищенный режим процессора.
Есть специальный сегмент, называемый TSS. В нем сохраняется состояние задачи (все регистры, указатели стеков для всех колец защиты и т.д.) и при необходимости служебные данные операционной системы.
По прерыванию от таймеру управление получает планировщик, который принимает решение какую задачу необходимо выполнить следующей, и выполняет инструкцию long jump на селектор новой задачи (jmp это один из способов, также можно сделать call или ret). При прерывании задачи, все ее состояние на аппаратном уровне сохраняется в TSS, а при передачи управления на новую задачу ее состояние загружается из ее TSS.

Чисто логические рассуждения, на истину никак не претендующие:
Что-то мне подсказывает, что диспетчеры потоков в ОС все же реализованы программно, состояния регистров каждого из потоков хранятся в глобальной памяти, иначе ограничения ЦПУ накладывали бы ограничения на кол-во потоков, количество которых даже сегодня определяется сотнями. Помимо этого подобная привязка может негативно отразиться на при переносе ОС на какую-либо архитектуру, отличную от х86.

PS
call для передачи управления не очень подходит, т.к. помещает адресс возврата в стек, да и retn тоже не наилучший вариант, т.к. без push'а он в этом качестве бесполезен.

PPS
По теме топика, SuspendThread, ResumeThread, GetThreadContent, SetThreadContent, все это Debug API, а отладчик, на сколько мне помнится, останавливает поток, пусть даже исполняемая команда и находится в критической секции.

Ну так эти сегменты и лежат в обычной памяти и ядро имеет к нему доступ как к обычной структуре.

Современные системы вообще используют малую часть возможностей защищенного режима: используются только 2 кольца защиты из 4, не используются защита на уровне сегментов, ...
Насчет call для переключения, почему не подходит? Выполняется задача, в какой то момент ей нужно запустить другую под-задачу, возможно даже в другом кольце защиты, она вызывает ее через call, когда под-задача завершается, управление возвращается к первой. Тоже можно сделать и с программными прерываниями int.
Возможности у процессора есть, только ими не пользуются... но это и к лучшему, чем меньше проверок будет делать процессор, тем быстрее будет ОС.

Я к тому что если эта задача не выполнится до того, как ее вытеснит другая, а в последствии будет продолжена, опять-же call'ом, в стэке будет мусор из адресов возврата. Вот про что я.

Ну так если задачу будет прерывать планировщик, он и управление будет возвращать не call-ом.
Про call я писал, только чтобы показать что переключать задачи можно разными способами...

На этот вопрос нельзя ответить однозначно.

На мой взгляд есть два пути.

1. Если приостановка используется для синхронизации работы потоков, тогда имеет смысл обратить внимание на рекомендацию от Microsoft (MSDN)


вот здесь http://lists.trolltech.com/qt-interest/2007-01/thread00346-0.html дан пример реализации class SuspendableThread

2. Если приостановка используется для других целей, тогда это можно "красиво" делать используя DebugAPI для Win, а для Linux нужно "перенимать опыт" у GDB отладчика. Они (отладчики) этим (приостановкой потоков) пользуются очень часто.

P.S. Здесь еще о приостановке потоков http://www.liveinternet.ru/users/optical_race/post76371150/