Чтобы глюков не было.

Состояние приложения может быть уже другим, а процесс требует выполнить то, что выполнять уже нельзя.

К примеру: Пользователь открыл файловый менеджер, поставил на загрузку файл. Файл улетел на сервер, но пользователь успел закрыть окно. А процесс требует обновления списка файлов после загрузки. Вылазит баг.

Давай перейдем от абстрактных проблем к реальным ситуациям. Можешь привести пример?

Т.е. есть два процесса: файловый менеджер и его дочерний процесс - upload файла. Файловый менеджер умер собственной смертью, а upload файла остался. Вопросы: 1) кто кого убивает, чтобы не было глюков? 2) почему upload файла не может выяснить, жив ли родитель, перед тем как запрашивать обновление списка файлов?

За этим должно следить ядро. Убить процесс должен файловый менеджер при клике на крестик.

Потому что это настоящий геморрой, который проще сказать, чем просчитать все варианты.

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

А дебаг превращается в сущий ад. С процессами чуть больше кода, но зато можно поставить console = true и понять где глюк.

Не совсем понял, чтобы не было глюков, убивает ядро или файловый менеджер? Кроме того, я правильно понял, что даже если пользователь закрыл файловый менеджер, upload файла должен продолжаться?

А какие есть варианты? По-моему все просто, когда файловый менеджер запускает дочерний процесс, между ними создается однозначная связь. Вижу два варианта: 1) ядро хранит дерево процессов и любой процесс может получить доступ к своему предку, 2) родительский процесс при необходимости передает ссылку на себя дочернему процессу.

А это как-то можно отменить? Хотя это собственно говоря несущественно.

И ещё кто-нибудь ... только через ядро. Послав запрос на закрытие процесса или процессов.

Это вообще не важно. Между ними в любом случае будет связь. Меня интересуют процессы, между которыми нет связи!

Ядро хранит процессы, по поводу дерева думал, но не уверен пока, что хочу напихать в стек, обоймы. Это не суть, так как протокол процессов позволяет расширять себя.

Ок. Давай другой пример.

У нас есть квадратик. В него мы грузим то список, то табы. Связи между ними никакой нет. Будет грузиться то, что выбрал пользователь. Однако если пользователь будет тыкать слишком усердно мышкой, то порядок следования может перепутаться в лучшем случае. И тут проверять родителей или есть или нет в квадратике чего нельзя. Процессы то асинхронные.

не, тут лучше такая модель: у каждого ресурса есть список принадлежащих ему ресурсов. при уничтожении родительского ресурса дочерние уничтожаются автоматически.

В этом случае получается есть владелец квадратика. По команде от пользователя он запускает в квадратике один из двух других процессов. Если в квадратике уже запущен какой-то процесс, перед тем как запускать другой процесс владелец квадратика должен убить текущий процесс (сообщить ему, что следует сворачивать удочки). Правильно? Но зачем такая терминология? То же самое можно сформулировать в терминах объектов (ресурсов). Необходимо лишь добавить возможность регистрировать создание объектов через какого-то внешнего арбитра (ядро).

не совсем подходит, например, upload файлов (не всегда дочерние процессы должны убиваться в случае смерти родителя)