freepascal.ru

жило было у меня ядрышко
ОС linux
в работу входило подключение к БД взять настройки и обслуживать устройства.

по пути наименьшего сопративления был выбран код



со временем деревья выросли. компьютеры стали маленькие, у стройств становится все больше и больше.

соответсвенно ядрышку приходится развиваться, вот в собсвеном и вопрос как ?

т.к. ось линукс и меняться не планируется, то платформо логично использовать fork

значит выходит 2 варианта

1,
процесс стартует
идет к базе, получает сколько устройств надо обслуживать, отключается от БД
распаралеливается на кучу процессов
из каждого конектится и работает по своему алгоритму
+ в принципе легко реализуем, да и глюков быть не должно
- куча коннектов к БД
- не знаю как с ними общаться и как логировать

2,
процесс стартует
идет к базе, получает сколько устройств надо обслуживать,
создаетна кучу процессов, передает им инструкции
общается с ними через именованые каналы (?)
+ один конект к БД
+ возможность создавать\убивать процессы во время работы из главного процесса
- не работал с именоваными каналами, не знаю их надежность


какие мысли ?

Второй вариант, только с сокетами? В плане надежности - вроде бы весь линукс через сокеты взаимодействует и не разваливается...

Когда я собирался сделать что-то подобное у меня возник вопрос:
Родительский процесс порождает кучку дочерних и должен с ними общаться, хоть через сокеты, хоть через пайпы (разницы никакой). Впрос вобственно как узнать какой из процессов готов принять порцию информации или наоборот желает на о чем-то поведать... дабы не попасть в deedlock. В винде есть WaitForMultipleObjects, в линухе только wait-семейство. Хотя есть функция select, которая позволяет выбрать сокет (мб и канал?) который готов принять данные или хочет что-то нам передать. Далее, у меня была ещё проблема с отслеживанием момента завершения дочернего процесса и получения кода возврата... тут нужно обрабатывать какой-то сигнал. Кстати, если этот сигнал игнорировать или обрабатывать не правильно, то у расплодяться зомби. Процессы - которые завершили свою работу и остаются в системе, пока кто-нибудь не вызовет wait (сейчас уже точно не помню):

man 2 wait писал(а):Стандарт Single Unix Specification описывает флаг SA_NOCLDWAIT (не
реализован под Linux), такой, что если он установлен, или обработчик
сигнала SIGCHLD установлен в SIG_IGN (что, кстати, не разрешено
стандартном POSIX), то завершившиеся дочерние процессы не становятся
зомби, а вызов wait() или waitpid() блокируется, пока все дочерние
процессы не завершатся, а затем возвращает код ошибки, устанавливая
errno в ECHILD.

Чем не устраивает TThread?

3. Создать мастер-процесс и несколько рабочих процессов. Мастер планирует список и получает от рабочих процессов результаты работы.

Вообще нужно понимать задачу. Например вариант, когда с базой работает только один клиент (процесс) годится если нагрузка на базу не большая и большая часть времени будет уходить, скажем, на обработку данных. Если нагрузка большая то работу с базой стоит отдать рабочим процессам (их число обусловленно эффективностью параллельной обработки, т.е. многопроцессорностью и возможностью СУБД работать с несколькими соединениями, я, например, использую от 3х, до 10 рабочих процессов).

Можно обойтись и без мастера. Т.е. есть какая-то очередь задачь, например она хранится в БД. Каждый рабочий процесс при завершении очередной обращается к базе (т.е. к этой очереди) за следующей. Вот и все. Количество соединений с СУБД ограничено количеством рабочих процессов.

..bw

PublicJoke писал(а):Чем не устраивает TThread?

я ему в фпц не доверяю, сколько уже на него жаловались да и в ДЦ тоже из-за него багов не мало было, пришлось кастылики рисовать.
да и какбы это более венждовая вещь как мне казалось =)

Sergei I. Gorelkin писал(а):Второй вариант, только с сокетами?

мастер прощес поднимает "сокет сервер" а остальные к нему конектятся ?
а в голом фпц они есть или надо доп компонеты типа инди юзать ?

shade писал(а):Впрос вобственно как узнать какой из процессов готов принять порцию информации или наоборот желает на о чем-то поведать...

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

bw писал(а):Можно обойтись и без мастера.

тогда управлять не получится или только через евенты, но в любом случее кто-то должен быть главнее =)
нагрузка на бд не большая, запустить процедурку с параметрами , но есть вероятность что в один момент времени захотят связяться все разом, тогда прийдется обождать. а конект из каждого, это в случае класик сервера птицы по процессу на устройство хотя больше сотни еще и не разу не было, а серверу то что, он железный =)

Attid писал(а):мастер прощес поднимает "сокет сервер" а остальные к нему конектятся ?
а в голом фпц они есть или надо доп компонеты типа инди юзать ?

Можно по-разному. Там же есть именованные сокеты (если два процесса знают нужное имя, они законнектятся - чем оно при этом от пайпа отличается, я даже не знаю), есть linux-specific "анонимные" сокеты (на самом деле, они такие же именованные, только не существуют в файловой системе). Соответственно можно сделать все наоборот - чтобы дети слушали, а родитель коннектился.
Что касается функций - юниксовое апи (fpsocket, fpbind и сотоварищи) в голом fpc есть по-любому, а дальше уже вопрос удобства.

Sergei I. Gorelkin писал(а):Соответственно можно сделать все наоборот - чтобы дети слушали, а родитель коннектился.

ну тогда если я правельно понимаю, то тогда надо открывать столько портов сколько детей . .

ладно пойду искать где почитать про сокеты можно.

Используй потоки, в чем проблема то?
Даже если проблемы с TThread используй API Linux непосредственно уверен что на это уйдет меньше времени и меньше кода, а значит возможных ошибок будет меньше. Сами же потоки в линухе нормальные? Они может дольше чем в винде создаются, но других проблем нет, на сколько я знаю.

..bw

bw писал(а):уверен что на это уйдет меньше времени и меньше когда, а значит возможных ошибок будет меньше.

я думаю об обратном.
в случае форка логика приложения все равно прямая и понятная, в случае процесов сама логика приложения извилистая и там проще запутаться. конечно это мое ИМХО =)

Могу порекомендовать отпортировать потоки из Common C++ (http://www.gnu.org/software/commoncpp/, качать отсюда ftp://ftp.gnu.org/gnu/commoncpp/), под Виндой и Линуксом работают без замечаний.

Я бы не назвал TThread в FPC 2.3.1 особо глючным. Во всяком случае, связанный с ним код у меня с винды на линукс переехал как-то без приключений и никаких изменений не потребовал. Что меня даже удивило...