23.12.2012, 17:05
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
Сообщение от x-yuri
|
а зачем процессам убивать друг друга?
|
Чтобы глюков не было.
Состояние приложения может быть уже другим, а процесс требует выполнить то, что выполнять уже нельзя.
К примеру: Пользователь открыл файловый менеджер, поставил на загрузку файл. Файл улетел на сервер, но пользователь успел закрыть окно. А процесс требует обновления списка файлов после загрузки. Вылазит баг.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
Последний раз редактировалось Gozar, 23.12.2012 в 17:08.
|
|
23.12.2012, 17:07
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
Давай перейдем от абстрактных проблем к реальным ситуациям. Можешь привести пример?
|
|
23.12.2012, 17:17
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
Т.е. есть два процесса: файловый менеджер и его дочерний процесс - upload файла. Файловый менеджер умер собственной смертью, а upload файла остался. Вопросы: 1) кто кого убивает, чтобы не было глюков? 2) почему upload файла не может выяснить, жив ли родитель, перед тем как запрашивать обновление списка файлов?
|
|
23.12.2012, 17:21
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
Сообщение от x-yuri
|
1) кто кого убивает, чтобы не было глюков?
|
За этим должно следить ядро. Убить процесс должен файловый менеджер при клике на крестик.
Сообщение от x-yuri
|
2) почему upload файла не может выяснить, жив ли родитель, перед тем как запрашивать обновление списка файлов?
|
Потому что это настоящий геморрой, который проще сказать, чем просчитать все варианты.
Если приложение простое, то там ещё можно выяснять жив родитель или нет, а если сложное, то количество вариантов растет с огромной скоростью. Количество процессов может исчисляться уже десятками и проверять всех родителей или ещё чего там может быть становиться проблематично.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
Последний раз редактировалось Gozar, 23.12.2012 в 17:24.
|
|
23.12.2012, 17:25
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
А дебаг превращается в сущий ад. С процессами чуть больше кода, но зато можно поставить console = true и понять где глюк.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
|
|
23.12.2012, 17:29
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
Сообщение от Gozar
|
За этим должно следить ядро. Убить процесс должен файловый менеджер при клике на крестик.
|
Не совсем понял, чтобы не было глюков, убивает ядро или файловый менеджер? Кроме того, я правильно понял, что даже если пользователь закрыл файловый менеджер, upload файла должен продолжаться?
Сообщение от Gozar
|
Потому что это настоящий геморрой, который проще сказать, чем просчитать все варианты.
|
А какие есть варианты? По-моему все просто, когда файловый менеджер запускает дочерний процесс, между ними создается однозначная связь. Вижу два варианта: 1) ядро хранит дерево процессов и любой процесс может получить доступ к своему предку, 2) родительский процесс при необходимости передает ссылку на себя дочернему процессу.
|
|
23.12.2012, 17:39
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
Сообщение от x-yuri
|
даже если пользователь закрыл файловый менеджер, upload файла должен продолжаться?
|
А это как-то можно отменить? Хотя это собственно говоря несущественно.
Сообщение от x-yuri
|
убивает ядро или файловый менеджер?
|
И ещё кто-нибудь ... только через ядро. Послав запрос на закрытие процесса или процессов.
Сообщение от x-yuri
|
когда файловый менеджер запускает дочерний процесс, между ними создается однозначная связь.
|
Это вообще не важно. Между ними в любом случае будет связь. Меня интересуют процессы, между которыми нет связи!
Сообщение от x-yuri
|
1) ядро хранит дерево процессов и любой процесс может получить доступ к своему предку, 2) родительский процесс при необходимости передает ссылку на себя дочернему процессу.
|
Ядро хранит процессы, по поводу дерева думал, но не уверен пока, что хочу напихать в стек, обоймы. Это не суть, так как протокол процессов позволяет расширять себя.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
|
|
23.12.2012, 17:49
|
|
猫
|
|
Регистрация: 07.06.2007
Сообщений: 7,504
|
|
Ок. Давай другой пример.
У нас есть квадратик. В него мы грузим то список, то табы. Связи между ними никакой нет. Будет грузиться то, что выбрал пользователь. Однако если пользователь будет тыкать слишком усердно мышкой, то порядок следования может перепутаться в лучшем случае. И тут проверять родителей или есть или нет в квадратике чего нельзя. Процессы то асинхронные.
__________________
Последний раз редактировалось Gozar, Сегодня в 24:14.
|
|
23.12.2012, 17:58
|
Профессор
|
|
Регистрация: 20.03.2008
Сообщений: 1,183
|
|
не, тут лучше такая модель: у каждого ресурса есть список принадлежащих ему ресурсов. при уничтожении родительского ресурса дочерние уничтожаются автоматически.
__________________
.ня
|
|
23.12.2012, 18:04
|
|
|
|
Регистрация: 27.12.2008
Сообщений: 4,201
|
|
В этом случае получается есть владелец квадратика. По команде от пользователя он запускает в квадратике один из двух других процессов. Если в квадратике уже запущен какой-то процесс, перед тем как запускать другой процесс владелец квадратика должен убить текущий процесс (сообщить ему, что следует сворачивать удочки). Правильно? Но зачем такая терминология? То же самое можно сформулировать в терминах объектов (ресурсов). Необходимо лишь добавить возможность регистрировать создание объектов через какого-то внешнего арбитра (ядро).
Сообщение от tenshi
|
не, тут лучше такая модель: у каждого ресурса есть список принадлежащих ему ресурсов. при уничтожении родительского ресурса дочерние уничтожаются автоматически.
|
не совсем подходит, например, upload файлов (не всегда дочерние процессы должны убиваться в случае смерти родителя)
Последний раз редактировалось x-yuri, 23.12.2012 в 18:14.
|
|
|
|