форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Несколько процессов, но один файл"

Сообщение от tian on 06-Апр-06, 17:34

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

1. "Несколько процессов, но один файл"

Сообщение от Hamper (ok) on 06-Апр-06, 17:46

Не изобретай велосипед! Syslogd уже давно изобретен :)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	2. "Несколько процессов, но один файл"
	Сообщение от tian on 06-Апр-06, 17:58
	>Не изобретай велосипед! Syslogd уже давно изобретен :) В принципе да, но ведь тут нужно не только отправить, но и получить данные. Хотя суммирование можно и возложить на что-то похожее syslog. Но тут придется держать еще один процесс. Я согласен, сделать можно, отправляя текущее значения в сокет. А если понадобиться в зависимости от полученных значений сделать некоторые действия ? Все-таки хотелось бы рассмотреть вопрос о выполнении данной задачи в рамках одного процесса. Я и говорю, что это несколько теоретический вопрос. Хотя кажется да, единственно возможный вариант - сокет. А уж далее сокет будет следить за тем, чтобы данные были корректны. Например, всем выдавать сразу значения текущие, но держать стек запросов. И потом когда процессы будут возвращать значения измененные (это числа, которые только увеличиваются, пока что), смотреть, что раньше или позже отправлено и корректировать общее значение. Но может быть есть другие решения ?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	3. "Несколько процессов, но один файл"
	Сообщение от MoHaX (ok) on 07-Апр-06, 04:59
	>>Не изобретай велосипед! Syslogd уже давно изобретен :) > >В принципе да, но ведь тут нужно не только отправить, но и >получить данные. >Хотя суммирование можно и возложить на что-то похожее syslog. >Но тут придется держать еще один процесс. >Я согласен, сделать можно, отправляя текущее значения в сокет. >А если понадобиться в зависимости от полученных значений сделать некоторые действия ? > >Все-таки хотелось бы рассмотреть вопрос о выполнении данной задачи в рамках одного >процесса. >Я и говорю, что это несколько теоретический вопрос. >Хотя кажется да, единственно возможный вариант - сокет. А уж далее сокет >будет следить за тем, чтобы данные были корректны. Например, всем выдавать >сразу значения текущие, но держать стек запросов. И потом когда процессы >будут возвращать значения измененные (это числа, которые только увеличиваются, пока что), >смотреть, что раньше или позже отправлено и корректировать общее значение. >Но может быть есть другие решения ? Может СУБД какую-нить прикрутить?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Несколько процессов, но один файл"

Сообщение от satelit on 07-Апр-06, 05:13

А добавь еще один свой процесс (или нить в рамках одного процесса), и скидывай ему данные, а он пусть их пишет, сортирует, в общем обрабатывает.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	5. "Несколько процессов, но один файл"
	Сообщение от tian on 07-Апр-06, 08:20
	Я немного поясню: Есть процесс  слушает входящие соединения на сокете. Ну и ес-но порождает другой процесс, если соединение есть. Тот процесс порождает еще один и затем еще (по конвейеру). Так вот тот последний (четвертый процесс) процесс должен считать данные (ну или получить их как-то) (статистика счетчиков различных), прибавить (или убавить) от текущих полученных счетчиков свои значения и снова их записать. Процессы порождаются почти случайно (нет закономерности), поэтому случай гонки очень даже может быть. Необходимо, чтобы между считыванием данных и записью новых значений другие процессы не могли вмешаться. Но вот очередность их может быть малость в принципе нарушена (в зависимости от даты рождения процесса, т.е. первый родившийся процесс может в принципе и вторым начать обрабатывать данные. Если блокировать файл - то можно относительно долго ждать получение ресурса (и хотелось бы эту процедуру вынести за рамки других процессов), либо если вдруг процесс зависнет, то другие уж не смогут получить ресурс. БД прикручивать неохота - слушком задача не та для решения при помощи БД. Да и смысл все-равно остается тот же. Видимо - все-равно должен присутствовать процесс-регулировщик, имеющий стек. В него сыплятся запросы на ресурс, он их ставит в очередь и выдает разрешения на доступ ресурса. Ну и ес-но имеющий таймер на ожидание освобождения ресурса, если что - принудительно освобождать ресурс и давать другому. Просто как я и говорил - эта задача скорее архитекрутного решения, теоретическая (хотя в действительности ее необходимо реализовать на практике). Вот satelit  я так полагаю, тоже склонен к такому подходу, только нить организовывать сложно, так как придется модифицировавть сам процесс. А вот сторонний процесс реализовать проще и надежнее.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]