RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Установка атрибутов файлов из Rexx


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Aleksey Tarasow, 2:5053/57, librexx.ru azimut21.ru azimut64.ru
To : Improver
Subj : Установка атрибутов файлов из Rexx
> > > > > Предлагаю сбрасывать полные имена залоченых файлов в очередь, например в RXQUEUE, а при завершении процесса удалять их оттуда... Или наоборот, сразу сбросить в очередь полный список всех файлов и каждый процесс будет удалять оттуда строки по мере их обработки. В любом случае, отсутствие дополнительных дисковых операций должно, по идее, дать прирост в скорости обработки.
> > > > Процессы которые работают с файлами запускаются хаотично в любом количестве и не чего не знают друг о друге. Количество файлов за раннее не известно, но с течением времени будет только расти. Лочится только текущий файл, то есть с остальными файлами другие процессы могут делать что угодно. Выходит что каждый файл нужно искать отдельно в актуальном списке лоченных файлов.
> > > > Можно ли в очередь кидать сообщения (разными процессами), многократно их читать (каждым процессом, перед началом работы с каждым файлом), и удалять выборочно (например по индексу и т.п.)?
> > > Удалять выборочно не получится, цитата из мануала по REXX:
> > > В процедурах работа с очередями REXX осуществляется с помощью следующих инструкций:
> > > PUSH Помещает строку в начало очереди (LIFO).
> > > QUEUE Добавляет строку в конец очереди (FIFO).
> > > PULL Считывает строку из начала очереди. Если очередь пуста, то строка считывается с консоли (STDIN:).
> > > Чтобы получить информацию о количестве элементов, оставшихся в очереди, используйте функцию QUEUED.
> > > Значит хранение списка лоченых файлов потребует, как минимум, создания некоторой процедуры для считывания всей очереди, удаления из ней нужной строки и сброса оставшихся данных назад... Тогда по второму варианту будет проще сделать, алгоритм примерно такой:
> > > 1. *Один* процесс создаёт именованную очередь и отвечает за её наполнение, т.е. постоянно с некоторой периодичностью ищет новые файлы и добавляет их в конец очереди (QUEUE).
> > > 2. Все остальные процессы просто читают с удалением строку с именем файла из начала очереди (PULL) и обрабатывают этот файл нужным образом. Если очередь пуста, то процесс ждёт появления строки, или завершают свою работу -- это как решишь сам.
> > > Но тут есть такой момент: в документации по REXX также сказано, что синхронизация запросов (когда два процесса, имеющие доступ к одной и той же очереди, получают данные из этой очереди в порядке регистрации их запросов) возлагается на пользователя и не обеспечивается подсистемой, на время чтения все процессы для синхронизации должны выставлять какой-нибудь флаг, для совместимости на разных системах можно, например, изменять значение системной переменной...
> > Обработка ВСЕХ файлов подряд возможна, но это скорее исключение. В большинстве случае будет проводиться обработка части файлов, выбранных по признаку (в данном случае дата зашифрованная в имени файла). Поэтому помещать в очередь нужно имена лоченных файлов (список доступных файлом макрос получает при запуске по поиску SysFileSearch).
>
> Вопрос: все запускаемые обрабатывающие макросы фактически одинаковые, или у них есть отличия в параметрах поиска файлов?

Варианты скриптов, ограничены, в теории 4-10 шт (сейчас 4). По сути это аналог баз данных (точнее отдельных команд select, insert и т.п.), только на rexx. Они максимально унифицированы, все что смог сделал одинаковым до комментариев. Работа с файлами, внешними данными, передаваемым данными и т.п. - одинакова (принципиально, иначе все теряет смысл).

> > В параллельной ветке посоветовали обратить внимание на семафоры. Предварительно нашел команды по работе с ними в последней версии RexxUtil в OS/2 и в Регине. Ни когда не работал с ними. Буду изучать это направление, ближайшие пару дней.
> Да, можно и семафорами разрулить... Но что-то меня смущает то, что при озвученной задаче количество семафоров может неконтролируемо расти, а очередь, всё-таки, будет всего одна, если что-то пойдёт не так, то почистить или удалить её можно запросто.

Согласен, есть такая опасность. Но и количество одновременно запущенных скриптов (файлов), так же ограничено системой (скользкий момент, до конца его не проработал). Берется как аксиома, что скрипты должны работать ограниченное время (максимально короткое), а после закрываться подчищая все за собой. А так же ставящие задачи не предусматривают сильного наплыва одновременно запущенных скриптов (я рассчитываю до 20 в пике).
Но законы Мерфи ни кто не отменял. Так что готовимся к худшему :)

С семафорами, я раньше не работал. Хотя бы изучу технологию, да же если здесь не пригодиться.

Tue 13 Jan 2015 13:02 Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.