Можно ли узнать, ожидает ли процесс в заблокированном состоянии при вызове Receive () в Linux? - PullRequest
0 голосов
/ 19 июня 2009

Моя основная цель - выполнять процессы один за другим циклически, пока один вызов не получит () и не заблокируется, так что выполнение переключается на следующий процесс в очереди. Существует приложение контроллера, которое написано на Java, и оно выполняет эти процессы (которые также являются Java-приложениями) с помощью Runtime.getRuntime (). Exec () и сохраняет возвращаемые значения, которые являются объектами Process.

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

Я могу перейти на любой уровень, если вы захотите, если это возможно. Моей первой мыслью было получить эту информацию из драйвера, а затем сообщить ее моему Java-приложению контроллера. Я написал сетевой модуль ядра Linux, который фиксирует операции отправки и получения, но AFAIK функция socket.receive () ничего не сообщает сетевому драйверу.

Итак, я думаю, что есть варианты получить эту информацию из JVM, каким-то образом получить ее из команды linux или около того, или, возможно, через модуль ядра linux?

Каковы ваши предложения?

Ответы [ 6 ]

1 голос
/ 20 июня 2009

Не знаю, поможет ли это вам, но вы можете получить информацию о состоянии потока Java на вашем компьютере, используя локальное присоединение.

1) Добавьте tools.jar в ваш classpath и используйте VirtualMachine.list (), чтобы получить список запущенной JVM на вашем компьютере.

2) Присоединение к JVM, обработанному с использованием VirtualMachine.attach (virtualMachineDescriptor)

3) Получить адрес локального соединителя, vm.getAgentProperties (). Get ("com.sun.management.jmxremote.localConnectorAddress");

4) Используйте JMXConnectorFactory.newJMXConnector (...) для подключения к JVM

5) Из поиска JMX-соединения найдите ThreadMXBean

6) Из ThreadMXBean вы получаете массив ThreadInfos, который описывает все потоки в JVM.

7) Из TheadInfo # getThreadState () вы можете проверить, является ли состояние ThreadState.BLOCKED

1 голос
/ 19 июня 2009

Если вы хотите знать, заблокированы ли ваши потоки или что именно они заблокированы, вы можете либо создать дамп потока, либо использовать инструмент, подобный jvisualvm , чтобы присоединиться к процессу и посмотреть (в jvisualvm вы подключаетесь к процессу, берете дамп потока и просматриваете активность каждого потока).

1 голос
/ 19 июня 2009

Вы смотрели на systemtap ? Должно быть доступно на последних системах Fedora.

Лучший Андерс

0 голосов
/ 09 июля 2009

Вы можете просто отправить сигнал ВЫХОДА (Ctrl- \ на консоли), чтобы получить дамп потока.

0 голосов
/ 19 июня 2009

Здесь есть несколько моментов. Планировщик Linux достаточно умен, чтобы предотвратить заблокированную задачу. Это означает, что если вы вызываете receive () и ничего не ожидает получения, ваша задача, вероятно, будет переведена в спящий режим до того времени, когда вызов вернется. Вам не нужно обрабатывать планирование; ядро Linux сделает это за вас.

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

Конечно, простая проверка состояния задачи может не сказать точно, чего вы хотите. Если ваше состояние задачи TASK_INTERRUPTIBLE, оно говорит вам только о том, что ваша задача ожидает что-то , но выяснить, что это такое, может быть не просто. Точно так же ваша задача может находиться в состоянии TASK_RUNNING и фактически не работать в ЦП в текущий момент (но, по крайней мере, в состоянии TASK_RUNNING вы знаете, что ваша задача не заблокирована).

0 голосов
/ 19 июня 2009

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

Вы не можете делать предположения о том, как дочерние процессы реализуют чтение своих сокетов. Они могут использовать recv, или select, или poll и т. Д. Для ожидания сетевых данных.

...