Количество CLR и экземпляров GC, работающих на машине?
Это все, что вам нужно сделать:
var myVariable;
$.ajax({
'async': false,
'type': "POST",
'global': false,
'dataType': 'html',
'url': "ajax.php?first",
'data': { 'request': "", 'target': 'arrange_url', 'method': 'method_target' },
'success': function (data) {
myVariable = data;
}
});
ПРИМЕЧАНИЕ: Использование «асинхронного» не рекомендуется. См. https://xhr.spec.whatwg.org/ .
4 ответа
У каждого процесса будет своя собственная копия CLR в качестве хост-процесса. Однако, поскольку CLR на самом деле представляет собой всего лишь пару DLL, Windows сможет совместно использовать библиотеки DLL между процессами. Для получения дополнительной информации см .: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx
Управляемый exe-файл имеет дополнительный заголовок CLR в дополнение к Переносимый исполняемый файл (формат PE) . Теперь ОС может определить, является ли запущенный исполняемый файл «управляемым» исполняемым файлом, и, следовательно, загружает среду CLR «за кулисами» и передает ей управление.
- mscoree. dll - это оболочка DLL (последняя версия этого файла всегда присутствует в папке Windows / System32 и, следовательно, знает, как загрузить текущую и более старую версии CLR).
- mscorwks.dll - это фактическая реализация CLR. Вы найдете несколько версий этой dll, если у вас установлено несколько версий фреймворка. Правильная версия этой dll загружается с помощью shim dll.
Из вышесказанного следует, что каждый управляемый исполняемый процесс будет иметь свою собственную копию CLR (2 DLL). ManagedExecutable1 может использовать CLR v1, тогда как ManagedExecutable2 может использовать CLR v2. На данный момент они не переданы.
Правильная версия этой dll загружается с помощью shim dll.
Из вышесказанного следует, что каждый управляемый исполняемый процесс будет иметь свою собственную копию CLR (2 DLL). ManagedExecutable1 может использовать CLR v1, тогда как ManagedExecutable2 может использовать CLR v2. На данный момент они не переданы.
Правильная версия этой dll загружается с помощью shim dll.
Из вышесказанного следует, что каждый управляемый исполняемый процесс будет иметь свою собственную копию CLR (2 DLL). ManagedExecutable1 может использовать CLR v1, тогда как ManagedExecutable2 может использовать CLR v2. На данный момент они не переданы.
Сборщик мусора является частью среды CLR и, следовательно, также отличается от процессов для управляемых исполняемых файлов.
Я бы сказал, что вы можете легко подсчитать процессы, которые запускают или загружают CLR, проверяя загруженные dll. Но я не уверен, сможете ли вы подсчитать количество запущенных доменов приложений. Но я не думаю, что это ваша цель.
Есть только одна куча на процесс и один сборщик мусора, который приостанавливает все управляемые потоки во время сбора. Таким образом, вы можете перебирать процессы и проверять, загружен ли mscorlib, если да, то можете предположить, что это работает с .NET CLR и GC. Я уверен, что должны быть более эффективные способы определить, размещен ли процесс в среде CLR, пожалуйста, проверьте также CLR API.
Чтобы лучше понять, попробуйте книгу Джеффри Рихтера «CLR через C #».
Код ниже повторяется .NET процессы
// Import these namespaces
using System.Diagnostics;
using System.ComponentModel;
// Here is the code
Process[] prcs = Process.GetProcesses();
foreach (Process prc in prcs)
{
try
{
foreach (ProcessModule pm in prc.Modules)
{
if (pm.ModuleName.Contains("mscorlib"))
{
Console.WriteLine(prc.ProcessName);
}
}
}
catch (Win32Exception exWin)
{
// Cannot detemine process modules ... some will deny access
}
}
CLR - это фактически компонент, который преобразует MSIL в собственный машинный код. Затем этот машинный код выполняется в собственном процессе для каждого приложения.
А в мире .NET процесс тесно связан с доменом приложения . Вот почему я думаю , это - хорошая отправная точка.