Гм. Вообще-то ничего пока не понял, где вернуть и как вернуть, но это ладно, разберусь завтра, если только...
Вот это меня насторожило
Sets the interface pointer that the common language runtime (CLR) can use to get the host's implementation of
Это что — для всей CLR или же для моего процесса ? Я не могу вмешиваться в работу CLR в целом, я хочу задать ограничение только для своего процесса. Ну как в JVM это сделано — опция JVM и все дела.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Гм. Вообще-то ничего пока не понял, где вернуть и как вернуть, но это ладно, разберусь завтра, если только...
CLR это тупо COM server, ты можешь его сам поднять из native приложения и подсунуть ему реализацию ряда интерфейсов, с помощью которой его работой можно порулить.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Гм. Вообще-то ничего пока не понял, где вернуть и как вернуть, но это ладно, разберусь завтра, если только...
EC>CLR это тупо COM server, ты можешь его сам поднять из native приложения и подсунуть ему реализацию ряда интерфейсов, с помощью которой его работой можно порулить.
Здравствуйте, EvilChild, Вы писали:
EC>CLR это тупо COM server, ты можешь его сам поднять из native приложения и подсунуть ему реализацию ряда интерфейсов, с помощью которой его работой можно порулить.
Можно чуть поподробнее ? У меня все же нативного приложения нет, есть только управляемое. Это во-первых. Во-вторых, если я создам инстанс COM-объекта, то могу я быть уверен, что когда кто-то еще попробует CoCreateInstance, ему не дадут те же параметры ? Для остальных-то приложений ничего сказано не будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
EC>>CLR это тупо COM server, ты можешь его сам поднять из native приложения и подсунуть ему реализацию ряда интерфейсов, с помощью которой его работой можно порулить.
PD>Можно чуть поподробнее ? У меня все же нативного приложения нет, есть только управляемое. Это во-первых.
Придётся сделать.
Некоторое представление о теме можно получить Implement a Custom Common Language Runtime Host for Your Managed App и CLR Hosting APIs, ну и погуглить по custom CLR host можно.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Это что — для всей CLR или же для моего процесса ?
Весь CLR живет внутри некоторого процесса.
Сказку про Кощея читал? Вот точно так же управляемый код исполняется внутри CLR; а сам CLR исполняется под управлением хоста, который предоставляет ему интерфейс с внешним неуправляемым миром.
Когда ты запускаешь на выполнение дотнетовский екзешник, первым делом стартует его неуправляемая часть. Эта неуправляемая часть инициализирует дефолтный хост, который загружает CLR, и отдает ему на исполнение управляемую часть приложения.
Поскольку в майкрософт работают хорошие люди, они опубликовали рукоятки по управлению CLR. Таким образом, любое неуправляемое приложение может захостить внутри себя управляемый код. Так, в частности, поступают IIS и SQL Server.
Ты тоже можешь поступить точно так же; именно хост определяет разнообразные низкоуровневые политики взаимодействия CLR и неуправляемого мира.
В частности, тонкости управления распределением неуправляемой памяти ложатся на него. Так что хозяин хоста может как угодно ограничивать CLR, выбирать политику размещения выделяемых регионов, и так далее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Это что — для всей CLR или же для моего процесса ? S>Весь CLR живет внутри некоторого процесса.
Ну когда ты перестанешь мне лекции читать ? Неужели трудно понять, что коли это все COM-сервер, то и вопрос мой — будут ли эти настройки, которые я сделаю, относиться только к инстансу CLR как COM-объекта в данном процессе или же в других процессах (скажем, запущенных после) тоже ? Кто мешает этому COM-серверу их запомнить ? Тем более, что я этот вопрос конкретизировал в письме к EviChild.
А впрочем, можешь не отвечать. Все равно никакое нативное приложения я делать не буду — игра не стоит свеч и из пушек по воробьям не стреляют. Если это нельзя в опциях указать и потратить на это 1 минуту, а надо самому из-за таких пустяков поднимать COM-сервер — найду другое решение.
Здравствуйте, EvilChild, Вы писали:
PD>>Можно чуть поподробнее ? У меня все же нативного приложения нет, есть только управляемое. Это во-первых. EC>Придётся сделать.
Вопрос снят. Я был готов потратить на решение этой проблемы не более 5 минут — установить некую опцию и все. Если это намного сложнее — найду другое решение.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно ли как-то указать ей максимальный размер? То есть больше такой-то величины — не расти, OutOfMemory.
А тебе именно vm size интересен или working set?
Если working set, то есть Process.MaxWorkingSet. Если же vm size, боюсь без unmanaged ничего не получится: либо CLR hosting как писали выше, либо Job objects (CreateJobObject/SetInformationJobObject(JOB_OBJECT_LIMIT_JOB_MEMORY...)/AssignProcessToJobObject), что будет приводить не к OutOfMemory, а просто к убийству процесса ОС. Ну и ещё можно "мягко" поиграть с GC.AddMemoryPressure, но это не лимит а так...
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Ну когда ты перестанешь мне лекции читать ? Неужели трудно понять, что коли это все COM-сервер, то и вопрос мой — будут ли эти настройки, которые я сделаю, относиться только к инстансу CLR как COM-объекта в данном процессе или же в других процессах (скажем, запущенных после) тоже ?
Очевидно, не будут. PD>Кто мешает этому COM-серверу их запомнить ? Тем более, что я этот вопрос конкретизировал в письме к EviChild.
Тот факт, что он живет в рамках отдельного процесса. Это как джава-машина: она работает сама по себе, и никак с другими джава-машинами не общается.
PD>А впрочем, можешь не отвечать. Все равно никакое нативное приложения я делать не буду — игра не стоит свеч и из пушек по воробьям не стреляют. Если это нельзя в опциях указать и потратить на это 1 минуту, а надо самому из-за таких пустяков поднимать COM-сервер — найду другое решение.
Воля твоя. Имхо, все необходимые приседания можно было сделать за то время, которое ты потратил на эту дискуссию.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну когда ты перестанешь мне лекции читать ? Неужели трудно понять, что коли это все COM-сервер, то и вопрос мой — будут ли эти настройки, которые я сделаю, относиться только к инстансу CLR как COM-объекта в данном процессе или же в других процессах (скажем, запущенных после) тоже ? Кто мешает этому COM-серверу их запомнить ? Тем более, что я этот вопрос конкретизировал в письме к EviChild.
Последовательность примерно такая:
инстанцируешь CLR
передаёшь ему свою реализацию требуемых COM интерфейсов
