Делаем отгружаемые сборки: взаимодействуем между доменами без маршаллинга

[IaIojek]

Одна деталь: не факт, что указатель всё время будет валидный. Объекты ведь могут перемещаться по памяти. И они будут перемещаться.
Тут стоит попробовать передать GCHandle этого объекта, но я не уверен, что среда не схватит за руку при попытке использовать. И даст ли она вообще использовать или отругается на то, что в использующем домене нет объекта с таким handle'ом.

[sidristij]

При перемещении объектов эти указатели также будут фикситься, поскольку объекты разных AppDomains создаются в единой куче. Разницы по памяти для них никакой. Это раскрыто в этой статье

[kekekeks]

Они теоретически могут перемещаться, но по факту, если мне не изменяет память, в текущей реализации GC не занимается дефрагментацией кучи. GCHandle нужен, чтобы GC не собрал объект, пока мы тупим.

[int19h]

Еще как могут. Можете убедиться сами.

using System;
using System.Runtime.InteropServices;

class Foo {
    public int Bar;
}

unsafe class Program {
    static void Main() {
        Foo foo = null;
        for (int i = 0; i < 10000; ++i) {
            foo = new Foo();
        }

        fixed (int* p = &foo.Bar) {
            Console.WriteLine((IntPtr)p);
        }

        GC.Collect();

        fixed (int* p = &foo.Bar) {
            Console.WriteLine((IntPtr)p);
        }
    }
}

[sidristij]

Надо указатель защитить через совмещение с полем типа object по одному смещению в структуре. Тогда GC сам поправит указатель

[int19h]

Их так нельзя совмещать, верификатор не даст при запуске. Можете сами попробовать.

Но тут идея была не в том, чтобы от этого как-то защититься, а наоборот, что это легко наблюдаемый эффект.

[sidristij]

При определенной комбинации структур и классов на full trust пропускает. Можно собрать тип, который и в partial отработает. Я сейчас в поезде, отпишусь как сделаю, но уже в будни

[int19h]

Если вам известно, как собрать такой тип, который работает с полноценной верификацией — это уже дыра в песочнице. Вы бы тогда сначала лучше отписались сначала на [e-mail]…

[kekekeks]

А, видимо, перемещаются, когда меняется поколение.

[szKarlen]

Могут :) Works on my machine ©
Наблюдал такое при высоких memory pressure.

правильно говорит товарищ int19h в примере

Единственная работающая вещь — GCHandle, где адрес Target обновляется.
Правда есть баг, но это уже из другой оперы.

[Gargoni]

Не совсем понятно, а как вы раньше создавали объекты в другом домене без маршалинга по ссылке и ремотинга? Вы когда будете вызывать метод у объекта из другого домена параметры также будут передаваться по правилам междоменного взаимодействия сериализация или MarshalByRefObject

[sidristij]

Здесь идет работа с не-MarshalByRefObject, потому междоменное взаимодействие между доменами отсутствует

[Gargoni]

А это будет работать на другой ОС или на другой версии фрэйм корка?

[kekekeks]

Никак, это чёрная платформо-специфичная магия.

[sidristij]

Это работает на всех версиях CLR

[mayorovp]

А что, собственно, произойдет, если выгрузить домен, пока в памяти остаются объекты, относящиеся к определенным в нем типам?

И, кстати, в какой домен попадёт сборка, загруженная из метода, определенного в таком переданном между доменами объекте?

[sidristij]

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

Зависит от того, из какого домена будет произведен вызов. Т.е. по сути, конструктор типа не должен содержать обращения к типам, которые потребуют загрузки в чужой домен, поскольку конструктор вызывается в дочернем домене. Остальные методы могут вызывать что угодно. Для конструктора этого можно избежать, если вызвать его отдельно. Для этого можно создать массив, размер которого будет равен или больше размера экземпляра объекта и изменить его адрес таблицы вирт методов на адрес нашего типа, тем самым избежав вызова конструктора из дочернего домена. Далее, получив указатель на объект можно вызвать конструктор напрямую.

[sidristij]

Я понял проблему… Надо чтобы все грузилось в дочерний… а тут проблемы не будет как раз… Надо, конечно, удостовериться… загрузки сборки будет требовать код дочернего домена, значит загрузится в дочерний

[Gargoni]

1 Я думаю ошибка доступа на уровне ОС
2 Скорее всего в том который можно выгрузить

[Bond_algotrade]

Отличная статья! Прям уличная магия какая-то)))

Подскажите, пожалуйста, возможно ли передать между доменами Вашим способом сборку в которой имеются классы не помеченные как сериализируемые? Где только не копался не могу найти способ разблокировать сборку после использования. В моем случае скорость не так важна, важно получить экземпляр класса в сборке с несериализируемыми данными и выгрузить ее (разблокировать) для дальнейшей работы. Можно это сделать как-то проще?

P.S. Спасибо за хорошие примеры!

[hack2root]

Парни, вы меня удивляете. Каждый раз, когда кто-нибудь изобретает велосипед с квадратными колесами, никто не спрашивает себя а как это будет работать в продакшене.

Во-первых, код не компилируется — не преведена реализация EntityPtr. Во-вторых, та реализация, которая существует (http://habrahabr.ru/company/luxoft/blog/219619/) — не работает на Mono. (До свидания, мой маленький Apple, до свидания до новых встреч!)

В третьих, ну неужели опять кому-то пришло в голову, что использование доменов приложения (как полагаю, уже исключительно на платформе Windows) — тормозит из-за сериализации? Ну, не делайте сериализацию — кто мешает. Но делайте стандартыми средствами, а не с использованием бубна.

Ну, реально — работает только на некоторых платформах на базе ОС Windows, а как только что-то поменяется компилятор, сборщик мусора — ваше глючное, непродуманное решение можно будет выкинуть в трубу. Да, по поводу платформы Windows — это решение не будет работать в средах (.NET) с настроенной параллельной сборкой мусора в отдельном потоке, например в ASP.NET приложениях, серверах Windows Server и т.п.

В общем, энтерпрайз сказал своё слово

[sidristij]

Обычно не отвечаю на такие комментарии, но все же.

1) дана ссылка на проект в GitHub — вы вообще проборавли компилировать? Или потрепаться зашли?
2) кто сказал что решение глючное? вы же так его и не попробовали скомпилировать?
3) вы мешаете в одном абзаце enterprice и Mac OS X. Много ли .Net Enterprice вы знаете на Mac?
4) кроссплатфроменность на .Net еще не достигла того уровня чтобы тыкать ее отсутствием
5) где связь между параллельной сборкой мусора и кроссдоменным взаимодействием?

Мне кажется, вы не понимаете сути того, о чем говорите