Мост # 3 - специализированный компьютер для чтения дискет (Страница 8 из 8)

Сделал управление накопителями, можно подключать-отключать.
Из визуально-видного: пока нельзя просмотреть список снятых образов (на web "Файлы на Мосту").

А так, для этапа 0, всё выглядит окончательно. Можно смотреть тут:
http://............../
Будет доступно до 11 мая примерно.

Заметки:
1) Скорость на 140ке считается неправильно: висит константа около 195 мс/оборот: там сама архитектура измерения неправильная, позднее буду переписывать, но там будет много работы.

2) Можно менять IP-шник, но после смены верните обратно :) Иначе после перезагрузки устройство исчезнет из вида.

3) Операционку можно перезагружать, но только если IP-ник правильный. Иначе после перезагрузки устройство исчезнет из вида.

4) Устройсво нельзя выключать. Сам обратно не включится.

Остальное можно. Даже отключать-подключать накопители (отключение тут - операция обратимая без механических действий).

USB-флешка воткнута, но она тормозная и, возможно, с ней съём будет идти медленнее.
Но можете поэкспериментировать :)

Часики идут по томскому времени, можете перевести на своё, если хотите.

Текущий ToDo:

Пара мелких замечаний по английскому:

0.042 ms for move the head to the zero track

Тут нужен предлог to: 0.042 ms to move

It is successfull final.

Тут пропущен артикль, плюс в слове successful только одна буква l. Но главное - фраза какая-то странная. Не понятно, а что тут по-русски должно было быть? Final - это последняя серия в сериале, последняя игра в турнире. А тут финал чего?
Если имелось в виду "Обработка завершена успешно", то можно было написать "Processing completed successfully".

To еще используется для обозначения результата действия или процесса. У for такого значения нет.

Я вот думаю - это все какие-то расплывчатые формулировки: "успешное", "хорошее". Может, указать конкретный результат, типа "образ создан/не создан"?

Немного выбивается из общего стиля. В остальных фразах местоимений нет, а тут вдруг "Я".
Предлагаю так:

The disk image has not been created. The main format could not be detected.

И остальные фразы (passive voice тут обязателен, потому что не "формат определил", а "формат был определен"):

The disk image has been created. The main format was detected and read without errors.
The disk image has been created. The main format was detected, but %d error(s) were encountered while reading.

+ ! рекурсивный вызов ui_client ! понятно почему, не ясно как избежать

Тоже любопытный программный случай.

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

Но если прога зависла, мы идём в Диспетчер Программ и там нажимаем "завершить". В этом случае сперва программа также получает мягкое предупраждение, но затем ОС может закрыть её и принудительно.

В *NIX этот механизм я знаю немного лучше. Там есть понятие "Сигнал" - это некое асинхронное сообщение, которое одна программа или ядро ОС может передать другой программе. Но отличие "сигнала" от прочих механизмов в том, что ещё до запуска программы операционка (или LibC ?) уже предоставляет программе обработчики сигналов. Причем некоторые сигналы программа не может игнорировать совсем, а на другие может повесить свой обработчик. Больше половины обработчиков по умолчанию завершают работу программы.

Это немного напоминает агатовский УПР-СБР: по умолчанию его проигнорировать сложно, но можно попробовать сменить заранее вектор, тогда шанс есть.

Есть довольно любопытные сигналы, например SIGSTOP - полностью приостанавливает программу. Совершенно не спрашивая её согласия :) Потом можно вновь разрешить работать, послав сигнал SIGCONT. Мне в винде этого, порой, не хватает (Какой-то процесс выжрал все рессуры, но закрывать его не хочется, а нужно вот сейчас сделать другую работу. Что делать?).
А ещё SIGKILL - классный сигнал безусловного мгновенного закрытия программы. Программа не может его игнорировать.

Так вот в Мосту3 есть два способа завершить программу:

1) Нажать на плате большую кнопку старт-стопа или в web-интерфейсе нажать 'Q'. Это мягкое завершение - программа получает сообщение о том, что пользователь просит её завершится и завершает работу, когда   ей будет удобно и как ей будет удобно.

2) Нажать в web-интерфейсе кнопку запуска проги. Если прога уже запущена, ей будет отправлен сигнал завершения SIGTERM. Это сигнал мягкий - прога может его игнорировать. Но, по умолчанию, обработчик этого сигнала завершает программу. Этот вариант нужен, например, на случай зависания программы.

Поскольку прога может обработать этот сигнал, она не закрывается сразу. Прерывается текущая исполняемая процедура (сигналы - механизм асинхронный!), после чего, кроме прочего, вызывается группа процедур atexit. В эти процедуры складываются всевозможные действия, которые программист считает нужным выполнить независимо от причин, по которым программа завершает работу. В случае моста3 там собраны всевозможные сообщения (на web-интерфейс, на дисплейчик платы, на кнопки с подсветкой) о завершении программы.

И вот тут возникала коллизия:
если сигнал прерывает процедуру обмена с ui-server остаётся заблокирован семафор обращения к ui-серверу. Он должен разблокироваться при завершении процедуры, но её прервали и код завершения не выполнен. А atexit нужно обратится к ui-server'у, чтобы сообщить о завершении проги. И он лезет в ту же процедуру, попадает на закрытый семафор и .. всё зависает. Открыть семафор некому.
В процессе поиска истоков проблемы я поменял тип семафора, чтобы в такой ситации он не блокировал всё, а сообщал об ошибке. Но саму проблему это не решает: сообщение о завершении работы пользователю не отправлено.

Отказываться от семафора нежелательно: он разводит во времени обращения к ui-серверу из разных тредов проги. Не то, чтобы у меня использовалось много тредов, но где-то они могут быть и на всякий случай семафор я использую.

Пришлось засесть за статьи по менеджменту сигналов. Важно не просто запретить прерывание обращения к ui-server, но и не запретить его во всех остальных случаях. Прога же может попасть в какой-то бесконечный цикл в декодерах, где-то ещё, она не будет проверять при этом мягкие просьбы из п1. И важно, чтобы хотя бы по п2 её можно было завершить.

Чистый C.
Я не знаю внутренности LibC, но, судя по поведению прог, сигнал прерывает выполнение любого кода в любом месте и, даже если я напишу какую-то обёртку, она не будет выполнена дефолтным обработчиком.

Возможно, в C++ ставится свой обработчик сигнала в RTL, который может позволить выполнится finally, а уже после этого завершает программу. Т.е. сперва он прерывает текущий код, потом, используя какой-то стек текущих finally, передаёт управление на них и потом уже завершает прогу.

> Я просто не представляю, как обработку управления ресурсами делать без try finally.

f2() {
  action1();
  if action2() < 0 then return; // сбой на каком-то этапе
  action3();
  // успешно всё выполнили
}

f1() {
  allocate(что нибудь);
 f2();
  free(что нибудь)
}

Речь об этом ?

Ну да, верно: если нужно как-то обработать исключения уровня "доступ к памяти запрещён" или что-то такое, то нужен свой обработчик сигналов.

В моём случае я использовал sigprocmask(). Это маскировка сигналов, причем пришедший сигнал не отбрасывается, он запоминается как необработанный. Как только маскировка снимается, сигнал будет обработан (в моём случае - обработчиком по умолчанию).

Т.е. полностью f1() у меня выглядит так:

void ui_client(char * msg_in, char * msg_out, int msg_out_max) {
  int r;

/* Так как вход в этому процедуру закрывается семафором, не следует допускать возможность её прерывания.
   Иначе семафор не будет открыт, а повторый вызов этой же функции из процедур группы atexit() приведёт чему нибудь плохому */
  sigset_t curset, oldset;
  sigemptyset(&curset);
  sigaddset(&curset, SIGINT);   // Ctrl-C, # 2
  sigaddset(&curset, SIGTERM);  // kill, # 15
  r = sigprocmask(SIG_BLOCK, &curset, &oldset);
  fatal(r, "UI client: sigprocmask set");
    
  r = pthread_mutex_lock(&io_mutex);
  fatal(r, "UI client: lock semaphore");

  ui_client_int(msg_in, msg_out, msg_out_max);
  
  r = pthread_mutex_unlock(&io_mutex);
  fatal(r, "UI client: unlock semaphore");

  r = sigprocmask(SIG_SETMASK, &oldset, NULL);
  fatal(r, "UI client: sigprocmask restore");
}

-----

Когда оставлял на выходные мост в доступе, предупреждал, что диск в 840ке долго обрабатывается.
Я думал дело  в тормозящей флешке, но проанализировал снятые образы и нашел причину:
позиционер флопика иногда пропускал шаг головки (причём только от края к центру, как правило где-то в районе нулевого трека). Странно, он это любит делать при недостатке питания, но сейчас он был воткнут напрямую в БП, даже минуя плату моста.

Дальше было так: всё это мост пытается декодировать, но получает от декодера ошибки. Соответственно, логика управления декодерами пытается перебирать параметры, настройки. Трек же не прочитался нормально, а что именно ненормально - её не беспокоит (обычно 1-2 сектора, залетевшие с чужого трека, особенно на 140-ке, особенно при программном "покачивании" головки - явление вполне привычное).

Но где-то в районе 30 цилиндра, по программе, есть обязательная рекалибровка. После неё голова встаёт на своё место и дальше все треки декодируются быстро. А поскольку после пробега от 0 к 160-му цилиндру идёт ещё пробег обратно, то младшие цилиндры читаются снова на обратном проходе. Логика декодеров видит, что они прочитались успешно и, следовательно, обзорного прохода достаточно.

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

Тут как раз тот случай, когда проще перечитать, чем тратить процессорное время на попытки выковырять то, чего нету. Но и "не шагающий" дисковод (кстати - трёхдюймовка) - тоже явление редкое... Надо ли тут что-то менять в коде ?

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

---

Доделал последний кусок в web-интерфейсе: удаление снятых образов. Заодно там же сделал возможность скачать образ или группу сразу в виде zip-архива. Не быстро (проца не хватает, чтобы быстро), но где-то 1 МБайт/секунду качается (компрессия налету, самая лёгкая, примерно 3:1). По FTP можно без компрессии можно забирать где-то 10 МБайт/секунду.

Супер! 👍

Мне удалось решить баг с битой переменной only140 и это оказалось тоже довольно любопытной историей.

Суть её в том, что firefox имеет странное поведение, не совпадающее с Chrome, например.
Когда FF восстанавливает вкладки при открытии браузера (если выставлен соответствующий режим),
он восстанавливает также значения полей в формах. Но похоже, что при этом, в интерпретаторе javascript,
автоматически синтезируется событие onchange.

Получается странная коллизия: мы ещё не запросили (или не получили ответ, например, если Мост3 сейчас выключен) конфиг-файл с шаблонами и номерами имён образов, но уже вынуждены их сохранить (onchange автоматически вызывает процедуру сохранения).
Ну хорошо, допустим, FF всё вытащил из своих хранилищ и прощелкал по всем полям onchange и всё ушло на сохранение в Мост3. Но вот что интересно: текстовые поля ввода восстанавливаются и синтезируют соответствующие поля конфига в памяти JS правильно, но не поле checkbox. На него события нет. Получается, что на сохранение в устройство уходит файл без only140, который как раз является checkbox.

Тут немного обсуждают эту штуку:
https://stackoverflow.com/questions/307 … ab-restore
и даже вроде как признали это багом, пока не исправили.

А тут оказывается, что вопрос про сохранение значений checkbox пока открытый:
https://wiki.mozilla.org/Session_Restor … o_be_saved

---

А когда-то мне довелось (в другом проекте) довольно долго бороться с тем, что некоторые браузеры пытаются даже синтезировать некоторые поля форм там, где этого совсем не требуется. Однажды у меня браузер решил, что очередное поле ввода является логином пользователя. И упорно делал автозаполнение. Попытки запретить autocomplete аттрибутом поля ни к чему не привели, также как и попытки явно задать значение поля пустым.
пришлось поставить таймер на одну секунду и через секунду после загрузки страницы, когда браузер уже выполнил автозаполнение, очищать поле.

===

На этом разработка Мост3 завершена.
В первое сообщение темы добавил все ссылки на видео и user manual.

Дальнейшее покажет опытная эксплуатация.