Дня доброго.
Свежачок подъехал.

https://wonderland.v8.1c.ru/blog/rabota-vneshnikh-komponentov-v-otdelnom-protsesse/

Но я смутно представляю область применения этой инновации, кроме как тестового запуска внешки в продакшене.

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

(1) Ну обычно ты это делаешь на тестовом серваке, потом в прод. Надо очень постараться, чтобы похерить стэк или получить этот прекрасный Access violation.

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

Ну не всем компонентам ты доверяешь. И часто например мою компоненту не хотят использовать из-за безопасности.
На самом деле маршалинг между процессами порякак 15 000 вызовов в секунду https://ru.stackoverflow.com/questions/630653/tcp-ip-%d1%81%d0%ba%d0%be%d1%80%d0%be%d1%81%d1%82%d1%8c-%d0%be%d0%b1%d0%bc%d0%b5%d0%bd%d0%b0/634019#634019

Вполне себе нормально. Учитывая, что можно еще и динамическую компиляцию использовать
https://infostart.ru/1c/articles/466196/

(4) О, дядь Сереж. Мы уж про тебя с твоей компонентой забывать начали, да. Спасибо что напомнид.

Кстати даже работая с комом проще работать через COM+ dllHost

(5) На здоровье! И тебе спасибо!

(3) Проще добавить кнопку "Отключить процесс", применение которого позволит считать процесс неактивным и заставить сервер создать новый процесс и начать переброску сеансов на новый процесс.

(3) Там возникает вопрос - как передавать несериализуемые данные. Да и сериализуемые данные передавать будет трудно, а я вот, например, мегабайты двоичных данных PDF передаю, чтобы tiff вытаскивать.

(8) зачем так сложно когда можно как в (0).
Да и вообще все в отдельных процессах - это модно

(10) Отключать процессы еще полезно, когда ты, например, в брэндмауэр прописал новый открытый ip адрес, а процесс 1С об этом не знает. И начинаешь ставить ему ограничение по памяти, чтобы перезапустился.

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

(12) Да сериализацию засунут и делов то.

(9) Какая там скорость по пайпам?

(0) крутая штука если я правильно понял, то же торговое оборудование в типовых конфах бывает заставляют зависнуть 1ску до победного (с ККТ такая беда была, когда 1ска не штатно закрывалась, повторный заход в РМК зависал намертво)...А тут походу можно будет убить процесс и все развиснет, освободить порт и заново подключить оборудование без выкидывания из 1ски.

(13) так из внешней компоненты же можно получать доступ к памяти 1с предприятия для передачи данных вместо передачи через стэк а теперь и он будет не общий

(2) Это ты авторам ВК-шек скажи. Не секрет, что вкшки для 1С пишут далеко не гении C++.

Ну так старый режим пока не отменяют

(16) тормозить будет

не уж то передача сотни мегабайт из процесса в процесс такая трудоемкая задача?

(20) Очень печально слышать это от тебя.

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

(22) Проверка прав процесса на память или возможность вызова сначала на уровне ОС, а потом на уровне процессора далеко не бесплатная, извини.

https://stackoverflow.com/questions/1235958/ipc-performance-named-pipe-vs-socket

(23)+ Это еще разным боксингом/анбоксингом не заморачиваться

(22) 1С по своей базовой привычке все сериализирует -десериализирует.

(26) ну это уже другой вопрос. если делать через ж.. то можно любую идею испортить

(26) С чего вдруг сразу сериализовать то. Просто будут через память передавать и всё. Они же не совсем идиоты. Будет медленнее, ну и хрен с ним. Просто твои 100 Мгб еще разок скопируют в общую память перед вызовом, да потом еще разок после вызова.

(28) так это через пайпы нужно. это нужно чтоб компонента умела

(29) А как ты сделаешь через пайпы? Ты из 1с в ВК передаешь 100 мег. 1С пайпы не умеет. Еще одну ВК делать чтоли? Да и нахрен они нужны. Для 100 мегов есть файлы.

(30) это она не умеет из кода 1с, а внутри вполне может уметь

ну кстати да, вместо пайпов вполне может быть SharedMemory

(28) У тебя куча разношерстных данных. Как ты их будешь в объекты на принимающей стороне засовывать? И есть еще готовый сериализатор. Что ты будешь делать?

(28) Мы же не непрерывный кусок кучи копируем. Мы набор объектов копируем, в которых данные могут валяться где угодно.

(32) Какая разница, какой там транспортный протокол, хоть через wmcopydata передавайте - будет быстро. Медленно - все это предобработать.

(33) А зачем объекты засовывать. Просто параметры передавать и всё. Ты же в ВК никакие объекты не передаешь. Только числа и строки.

(36) Я туда даже ОбщиеМодули отправляю.

(37) И шо можно делать в ВК с общими модулями?

Ну в любом случае сериализовать ничо не надо. Просто работает как COM. В COM же бывает в отдельном процессе объекты и всё прекрасно работает без всяких сериализаций.

(39) Ну, если ты создаешь его как standalone сервер - то да.

(36) > Только числа и строки.
Фирма 1С объявила об окончании поддержки компонент, написаных по технологии COM?

(39) Кстати, да, возможно они пойдут и этим путем.

(39) Хех, но тут вылазят Линуксоиды. Нет, не пойдут

Вот тут пора другой упрощенный формат ВК вводить
Чтобы на чистом C и прочих ЯП что могут c-shared dll легко было ВК писать

(44)+ Хотя нафик, просто встройте уже простейший веб-сервер в клиента 1С и все
Чтобы мог обработку внешнего события вызывать

(42) Таким путем и пойдут. Другого пути нет. Такую фигню можно за пару-тройку дней самому написать. Много ума не надо. Процесс, имитирующий 1с для ВК и RPC через что нравится.

правда ВК, думающие, что они работают в реальной 1с жестоко заглючат

(0)попробуй сделать ВК использующую Имейжд Мейджик, которую 1С сама использует. 1С вылетит.

(2)
>Надо очень постараться, чтобы похерить стэк или получить этот прекрасный Access violation.

Значит подавляющее большинство авторов ВК это и делает...
На самом деле нет - просто большая часть авторов ВК относится к C++ примерно как во встроенному языку - ну типа переменные, if'ы тут for'ы - что непонятного то?

P.S. И между прочим, причём тут стек - основной источник проблем от ВК - обычные перетирки памяти, от которых потом падает рабочий процесс.

(0) недавно с альфа-автой сталкивался, так она падает периодически из-за из их компоненты защиты. Вот тебе и продакшен.

(39) Com между процессами маршалит данные. Это может быть и ссылка на стороне сервера и сереализация десериализация

51+ Вообще в .Net Framework для таких вещей есть AppDomain https://docs.microsoft.com/ru-ru/dotnet/api/system.appdomain?view=netframework-4.8
Суть его в том, что AppDomain  выполняется в одном пространстве (процессе) с приложения но изолирован от приложения и его можно выгружать.
С переходом на .Net Core AppDomain стали платформозависмыми.
Сейчас очень модно использовать микросервисы https://habr.com/ru/post/249183/
Я в свое время сам написал .Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
https://habr.com/ru/post/323096/

Так, что 1С сделало то, что уже давно нужно было делать

Передача данных через границу процесса?
Тут вопрос,а зачем вообще нужна внешняя компонента,если доступ к ней через границу процесса?
Проще сразу в 1с реализовывать Tcp потоки для обмена двнными и забыть про внешние компоненты совсем.