Board.KolibriOS.org

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

geri777 wrote:И так, у меня в планах написать такую утилиту которая будет передавать рабочий процесс на другой комп(допустим в одной локальной сети). Как это будет работать: На обоих компах есть программа которую будем передавать(допустим калькулятор)>передаются все переменные на второй комп, после запускается программа на втором компе с места где она остановилась.
Сейчас вы можете написать предложения.
П.С.
Пишу на Си.

Можно попробовать через http.obj.

Не все приложения таким образом можно перенести. Будут отличаться системные объекты: id процесса, id окна, хендлы сокетов, данные при работе с файловой системой.

Veliant wrote:Не все приложения таким образом можно перенести. Будут отличаться системные объекты: id процесса, id окна, хендлы сокетов, данные при работе с файловой системой.

А зачем одинаковые ID процесса и окна?

И состояние памяти процесса придётся передавать. По сути реально всё. При условии, что программа в том же месте находится на другом компе. А то прога себя же не найдёт. Хотя перенести не всё можно, да. Те, кто использует какой-то специфичный драйвер, например. Короче, всё, что в ядре перенесено не может быть. Ну и надо следить, чтоб все выделенные куски памяти были выделены в тех же местах, что и на первом компе. Например такая ловушка: прога выделила 2 куска памяти, удалила первый кусок. Тут её клонировали на второй комп, и он копировал прогу, и выделил ту память, что 2ом куске. А находится он будет не там, где он был в оригинале. Он займёт место сразу памяти проги, то есть на месте первого куска. Короче адреса изменяться, после запуска прога наверняка рухнет.

GerdtR wrote:И состояние памяти процесса придётся передавать. По сути реально всё. При условии, что программа в том же месте находится на другом компе. А то прога себя же не найдёт. Хотя перенести не всё можно, да. Те, кто использует какой-то специфичный драйвер, например. Короче, всё, что в ядре перенесено не может быть. Ну и надо следить, чтоб все выделенные куски памяти были выделены в тех же местах, что и на первом компе. Например такая ловушка: прога выделила 2 куска памяти, удалила первый кусок. Тут её клонировали на второй комп, и он копировал прогу, и выделил ту память, что 2ом куске. А находится он будет не там, где он был в оригинале. Он займёт место сразу памяти проги, то есть на месте первого куска. Короче адреса изменяться, после запуска прога наверняка рухнет.

Я знаю о проблеме ячеек пам'яти. Я знаю что нада писать в свободные ячейки а не в те же которые были на 1 компе.
Еще вся программа будет останавливаться полностю перед тем как передеть все состояние.

На первый взгляд всё довольно просто: нужно передать содержимое всей выделенной памяти процесса, кроме самого кода... хотя нет, можно тупо всю память процесса вместе с кодом, тогда наличие программы на втором компе вообще не потребуется. Ну и содержимое регистров, естественно. Но. Правильно сказали про ID процессов. Что ты будешь делать, если требуемые ID уже заняты другими программами?

Pathoswithin wrote:Что ты будешь делать, если требуемые ID уже заняты другими программами?

А почему б не использовать другой ID?

This is an interesting problem to solve. I have often wondered through school how to perform this (on a linux machine). But as others have pointed out, it's kinda tricky.

Well, consider a small program which is like this :

/* smallprogram.c */ Now say, you run this program on MACHINE-1 and want to break after Line 1.
my_pid has been set to the current process ID on MACHINE-1 . Assume my_pid = 120.

Your registers and assembly of the program are set up according to current state of MACHINE-1.

Shifting this to MACHINE2 (Say you are able to perform a 1:1 copy somehow of the memory space):

MACHINE2 has:
libc loaded at 0x00BB0000.
130 processes running. So the next available pid will be 131.
Assuming everything else is the same as MACHINE1. (Very difficult in reality, but let's assume)
---
Some issues (There may be more) :

*As soon as your program tries to continue execution on MACHINE2, it will crash (as some other memory address is CALLED instead of print() )

*EVEN IF you were able to run without the issues you faced with libc, the value of my_pid is 120 (migrated from MACHINE-1). But the actual PID on MACHINE2 is 131. So all code that follows Line2 and uses the value of my_pid will behave in an irresponsible/unexpected manner.
---

A valid approach here might be to have some sort of a "CONTAINER" (jail, chroot, virtual memory space, or something along these lines) which is able to run a program inside it. But you write the container in such a way, that it automatically *fixes* all the addresses of the program running inside this container (or the approach is universal, and does not require address fixing in any manner).

Hope this helps.

Ну, такой программе, как калькулятор, это действительно пофиг. Но если прога имеет больше одного потока, да хоть открыла дочернее окошко, то смена ID сломает связь между ними.

выделить немного места в памяти для служебных данных. Эти служебные данные будут содержать адрес компа, ID и прочую инфу для совместимости.
Сами служебные данные никак не должны зависеть от ID.
Думаю, нужно это дело реализовать на уровне ядра.

ruwebstyle wrote:выделить немного места в памяти для служебных данных. Эти служебные данные будут содержать адрес компа, ID и прочую инфу для совместимости.
Сами служебные данные никак не должны зависеть от ID.
Думаю, нужно это дело реализовать на уровне ядра.

Если мне кто-то из hard программистов поможет ибо я боюсь лезть к ядру...

Если реализовывать на уровне ядра, то нужно делать серьёзную надстройку, чтоб все системные вызовы проверялись на "перенесённость". Возникает вопрос: для каких целей нам нужны такие возможности? Не проще ли создать формат "переносимых программ"? Добавить в заголовок бинарника таблицу ID процессов и прочих "региональных данных", которые будут редактироваться при переносе. Также добавить флаг, который будет запрещать перенос, если эти данные используются в данный момент.

Не программист, но может что то годное выражу:

а) Запуск копии ядра с программой в своей V86 машине. Тогда не будет проблем с ID.

Spoiler:

Сохранение:
1) сохраняется память занятая ядром со всеми "переменными";
2) сохраняется память занятая требуемой программой и её данными (тут же возникнет проблема, если программе потребуется файл с данными, лежащий где то, например её ini`шка);

Востановление:
1) востановили на отдельной страницы памяти ядро с данными
2) востановили программу с данными
3) передали управления процедуре востановленного ядра, где указали, что оно нынче не основное, находится по такому то смещению (на такой то странице памяти) и должно все системные вызовы транслировать(преобразовывать адреса и т.п.) в ядро "верхнего уровня", после чего оно продолжает исполнять программу, которая нечего не подозревая работает далее, имея в своём "виртуальном мире" тот же id, ту же версию ядра, те же функции и данные по тому же адресу, и т. п.

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

P.S. Возможность "заморозить" состояния ПК со всеми программами, передать его по сети/флешку/голубями на другой ПК и продолжить работу с того же места - это круто, но думаю очень непросто в реализации.

P.P.S. пришло на ум запускать виртуалку (qemu), сохранять в ней состояние машины и этот файл перекинув по сети востановить в другой виртуалки на другом компе. Для этого надо всего та собрать для колибри qemu

б) Реализовать "vnc-сервер", на ядре, которое по мимо экрана, ещё "рисует" в сетевые порты.

Spoiler:

Например - вещаем по порту 10 000 + id процесса. На втором компе подключаемся к требуемогу порту.
Тогда наличие такой же программы на втором ПК необязательно. Данные перекидывать необязательно. Но к сожалению работать и сохранять результат программа будет "на сервере", хотя тут же "под шумок" можно реализовать "монтирование" "серверных" (ram)дисков.

в) Записать и воспроизвести макросы.

Spoiler:

При запуске программы записывать движение мышки относительно элементов окна и нажатия клавиш.
Перекинуть этот файл по сети и на втором ПК, и там запустив туже программу "сэмулировать" движение мыши и нажатия клавиш.
Только как быть с данными, которые программа берёт не от пользователя. Например запустив текстовый редактор и загрузив в него текст мы его немного поправели, тогда для продолжения "правки" на другом ПК, нам нужно будет или тащить правливаемый файл или ту его часть, которая загружена в буфер редактора, но тогда мы его полностью не востановим.

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