visius,

Спасибо большое.

Потихоньку начал приподыматься GT.M на контроллере.
Теперь мой программист озадачился и много думает - работа похоже пошла.

Как там писали - М программисты настолько суровы, что заставляют работать промышленные контроллеры под МАМПСом и давать уголь на гора.

Смею заметить, что Linux, это со-овсем не DOS, и даже не Windows.
Но о-очень интересная штука, столько возможностей.
GT.M временно отложил, пока на С.
Но я к GT.M еще обязательно вернусь, и надеюсь что скоро.

Уважаемые ГУРУ GT.M!!!

Вот есть такой вопрос.

Мне необходимо, чтобы одна из баз размещалась в оперативной памяти.
Понятно, что при старте, ее образ(образ пустой базы) я копирую из файла на Flash диске в дисковый том, который создан в оперативной памяти при старте Linux.

Кто что может сказать по этому вопросу, у кого каой опыт, какие мнения, предложения?

Заранее спасибо.

servitЧто Вы скажете про использование RamDisk?
Под Windows
Под Linux

Понятно, спасибо.
*.dat файл и *.gld файл лучше оба располагат в RAM, или только *.dat файл?

servitPS: я не специалист по GT.M и Linux.

А жаль, с Вами приятно вести беседу.

ceshka_AlexKB
Кто что может сказать по этому вопросу, у кого каой опыт, какие мнения, предложения?

ни опыта, ни предложений, вопрос: вы в нее писать будете? и собираетесь выгружать при гашении системы? сколько памяти и размер базы?
Я уже в нее пишу и из нее читаю. Собственно не я, а ряд быстрых циклических процессов.
Такая база мне нужна для внутренней координации работы процессов, размер ее невелик, около 100 Кбайт. Хранит она только данные, актуальные в пределах текущего запуска приложения.
Мягкий рестарт, перезапуск GT.M, в этом случае подхватывает предыдущие данные. Крах GT.M и перезапуск Linux будет видить только пустую базу, которая создается след. образом:
При старте Linux создается дисковый том в оперативной памяти;
Копируется предварительно созданный файл пустой базы данных Temp.dat;
База определена в gld-файле уже на устройстве ramdisk;
В базу назначены глобалы (Work*, Temp*, другие).

Таким образом я работаю с глобалами в оперативной памяти без опасения ухайдокать Flash-память. Запись в другие базы осуществляется не часто и полностью контролируется прикладной программой.
Остается надеяться, что GT.M от нечего делать не долбит Flash-память, как этим занимается, в свое удовольствие, Windows.

ceshka_AlexKB,
что-то я не понял, Flash память это типа usb носителя в данном случае? Сдохнет в таком случае в момент: куча записей в секунду (само собой не знаю как именно у Вас). Возьмите SSD и будет вам щастье. И это уже наверное от реализации *NIX зависит а не от GT.M. Файл на Flash, перезапись интенсивная или не очень на ней, GT.M пишет в базу так, как решит приложение.
Flash память - это мой жесткий диск, другого нет. Так устроен контроллер. Поэтому "куча записей в секунду" перенаправляется на дисковый том в оперативной памяти. Если GT.M пишет в базу так, как решит приложение, то это превосходно, я не напрягаю Flash память излишней работой. Реализация Linux всего лишь позволяет мне создавать дисковый том в оперативной памяти. GT.M позволяет мне разносить данные по разным дисковым подсистемам. И это чудесно, прикладному программисту уже не нужно заботиться о специфике хранения, ему только нужно знать, что шустрые данные он должен размещать в глобалах с таким-то префиксом.

ceshka_,
Так ли я ответил на Ваш вопрос, может я чего не понял?

Странную штуку заметил в GT.M, при интенсивном открытии-закрытии сом-порта, наблюдаю утечку памяти. Освобождается память только при выходе из GT.M.

Уважаемые GT.M-Гуру, что скажете, какие мысли по этому поводу?

Конечно, это нештатная ситуация, но такие операции не часто, но приходится выполнять при некоторых условиях.

ceshka_...принудительно com-порт и всё о нём из памяти выгонять

Знать бы как всех их оттуда выгонять. Теперь еще кучу тестов с устройствами нужно провести.
Как говорят "ява-скрипачи" чистильщик мусора не всегда срабатывает. Иногда мусор таки оседает на дне.

Использую GT.M V5.1-000 Linux x86, поэтому поздно править.
Старше железо не позволяет.
Я уже думал о том, чтобы драйвера запускать не по Job из одного GT.M контекста, а как отдельные mumps -run "^routines", тогда у каждого драйвера будет собственный интерпретатор.
Хотя я еще досконально не проверил ничего по поводу Job, ведь там тоже будет у каждого свой собственный контекст (движок- просто обнаружил и вот тормошу Ваши Умы.