это робот-телескоп короче... надо останавливать наведение, пишу демона для остановки наведения по датчику дождя, жму кнопку в гуе, не работает.
Лезу в исходник гуя, там есть мной же написанная подпрограмма, которая ломится по сокету на специально мной же написанный демон для экстренной остановки, а кнопку надо рядом нажать... и теперь надо еще в 5 местах править код остановки съемки.
Походу, действительно придется килять всю эту байду по одному процессу. Хотя иногда не поможет, там, если что отвалится, процессы писал специально таким образом, что по киллу они могут восстанавливатся, если вдруг отвалился один из элементов всей системы надо отработать это, чтобы вся система выжила при нештатной ситуации.
Может это архитекутура? По идее это надо бы модулями писать, но в силу задействования в системе 2 видновых прог, технически проще сделать так, чтобы было много мелких програм. Но таким образом эти мелкие программы исчисляются полусотнями и начинают дублировать друг друга. Типа минус подхода к разработке, хотел попроще - получился муравейник. Было б модульно все - каждубю прогу пришлосбы по три четыре дня писать.
ну это я в жилетку вобщем поплакаться. Ибо сижу счас над виндовым кодом, запускающим с юниха по сокету определенную прогу, и не понимаю, почему оно не работает после экстренного срыва... Хотя раньше все работало.
ага, я иногда было, напишешь - не понимаешь, почему работает правильно ибо знаешь работать не должно. Рядом сидят программеры на сях/сях++ под юникс и сходят с ума, т.к. пишут проги, которые должны работать и они знают почему должны работать, но проги - не работают. :) БЫло и такое вобщем...
Воистину странно. Мне никогда не встречалась ситуация, когда для одной задачи легион демонов был бы в чём-либо выгодней нежели один демон, управляемый сигналами, параметрами и фифами.
счас посчитаю, есть 3 видеокамеры, есть 4 спец астрономических спецкамеры, 2 из спецкамер на винде работают, запускаются вижуалбейсик скриптом каждая(т.е. надо на каждую писать перлового демона для винды, который должен запускаться както с юнихка на съемку). Третья спецкамера пишет на сетевой диск(нет дров для юникса) и прога отваливается если валится основной сервер, как отработать надо ехать в фирму просить койче сделать с софтом. Какая либо из камер может отвалится (и это надо отработать) если с виндой произошло заражение вирусом или переполнился диск.
Вот например подробно про датчик дождя:
Он валит лог на видну (т.к. при перезагрузке сервера с сетевым диском прога датчика дождя не находит сетевой серверный диск и вываливается, потому приходится писать на винде tail -f в сокет на юникс). К данным датчика дождя должно коннектиться n юзеров по сокету, т.е. надо с винды валить лог на юникс, а в юниксе делать демон для одновременного подключения n юзверей по tcp на хост-порт.
Потом еще бывает электричесво выключается, т.е. надо отрабатывать отключение всей системы. Т.е. оно конечно просто, но в целом получается довольно сложно.
И теперь ответ на твой вопрос, ты прикинь, как писать один единый демон для всего этого? Это американцы могут взять и нанять роту программеров под юних и виндовс, у них бюджет офигенный, которые все эти мелочи учтут. А тут приходится юзать проги и учитывать их глюки каждой. Да так, чотб глюк одной не повлиял на работоспособность другой.
Ну незнаю, те на месте конечто виднее. Однако, из общих соображений, должно быть система управления, система ввода данных, система вывода результатов и система обработки нештатных ситуаций. Если демон один, каждая из их существует в единственном экземпляре и для каждого типа девайса/внешнего воздействия те придётся делать токмо "переходник" с этого в понятное твоему демону. При производстве полчищ демонов каждое из перечисленного приходится начинать с нуля, изза чего возрастает сложность структуры междемонного взаимодействия, объём кода и его структурная сложнось, что чревато багами и особенно сложностью баголовства.
> При производстве полчищ демонов каждое из перечисленного приходится > начинать с нуля, изза чего возрастает сложность структуры междемонного > взаимодействия, объём кода и его структурная сложнось, что чревато > багами и особенно сложностью баголовства.
так все и есть. Чето надо менят в онсерватории. Ладно спасибо за архитектурную, так чтоли поточнее сказать, помощь! :) Буду потихоньку думать как это все менять на предмет 4-х систем управления или что то в этом роде. путаться начинаешь вобщем блин.
И это правильно, а то что за ерунда в обсерватории у тебя творится -- демоны, перезапускающие оборудование на случай вируса в виндовой машине, анекдот же!