Владимир написал: исключить sleep и файловые операции
Это значит исключить эти операции из возможности помещать их в особый список. А далее смотрите мой текст. Хуже, чем сейчас не будет, если написанное будет реализовано корректно.
Roman Azarov написал: Мы обязательно примем данное обращение в работу и постараемся представить итоги его анализа.Заранее благодарим.
Текст данного комментария со Старателем не согласован, но надеюсь, что если, по его мнению, я написал что-то не то, он меня поправит. --------- Предложение1 (от Старателя). Мое краткое описание ситуации, устраняемое при реализации предложения Старателя, а далее цитаты. Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций. ---- Далее цитирую Старателя: «Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через задан-ное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить ско-рость вычислений байткода в циклах.». --- Далее цитирую себя: Комментарий 1. «То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua. Это примерно следующее: 1. Добавить в State поле счетчик. 2. При создании State счетчик = 0. 3. В цикле работы виртуальной машины Lua (исходник Lua 5.3.5 lvm.c) после текста: Instruction i; StkId ra;
добавить: if (++L-> счетчик > !00) { // 100 это конечно же надо задать константой -- L-> счетчик = 0; lua_unlock(L); lua_lock(L); }» --- Комментарий 2. « То, что вы предлагаете (это обращение к Старателю), я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде. При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания. Ваше предложение легко реализуемо в QLua.» --------------------------------------------------------------
Предложение2 (от TGB). Об оптимизации синхронизации в QLua. Не затрагивая существующей архитектуры обработки колбеков в QUIK, можно оптимизировать синхронизацию многопоточности QLua. Дело в том, что при синхронизации по умолчанию, как это, похоже, реализовано в существующей QLua, все вызовы C-функций имеют следующий общий вид: unlock ….; <Вызов C-функции>; lock ……; В операциях unlock и lock возможны переключения потоков. То есть, это ресурсоемкие операции. Если вызываемая C-функция выполняется быстро, как напри-мер, многие математические функции, то при существующей синхронизации, коэффициент полезного использования времени ЦП может быть очень низким : <Время выполнения C-функция > / (< Время выполнения unlock > + < Время выполнения lock >). Понятно, что в циклах QLua с обращением к коротким C-функциям QLua занимается в основном синхронизацией. Идея оптимизации состоит в том, чтобы у пользователя была динамическая возможность задания/отмены C-функций, которые вызываются без выше описанной синхронизации (ввести особый список). Сделать эффективную реализацию выше описанного несложно. Чтобы гарантировать обязательную «щель» для запуска колбеков, из списка допустимых C-функций, описанных в предыдущем абзаце операций, имеет смысл исключить sleep, а возможно, и еще какие-то функции обеспечения задержек по времени и файловые операции. Существенным положительным моментом описанной оптимизации является то, что она никак не затрагивает тех пользователей, которые не будут ее использовать. При ее применении, коэффициент полезного использования времени ЦП: 1) для функций из особого списка: <Время выполнения C-функция > / < Время анализа особого списка> 2) для обычных функций: <Время выполнения C-функция > / (< Время анализа особого списка> + < Время выполнения unlock > + < Время выполнения lock> ). При качественной реализации оптимизации можно добиться того, чтобы < Время анализа особо-го списка> было существенно меньше, чем (< Время выполнения unlock > + < Время выполнения lock>). --------
Предложение1 и Предложение2 совместимы при их совместной реализации, если реализация Предложения1 будет похожа на то, написано в Комментарий 1. Предложение1 устраняет критическую ситуацию. Кроме того его реализация проста. Поэтому Предложение1 имеет смысл реализовать в первую очередь.
Первое по важности это, как мне представляется, ценное предложение Старателя по устранению критической ситуации «подвисания» скриптов на длинных участках чистого Lua (без вызова C-функций). Ссылка на его комментарий: здесь Ниже его комментария есть два моих комментария о том, как это можно просто реализовать в QLua. ----- Второе предложение мое (ссылка на комментарий: здесь). В нем описывается вариант повышения эффективности выполнения в скриптах длинных участков с частым обращениям к коротким C-функциям. ------
Хотелось бы увидеть реакцию поддержки на эти два предложения.
Старатель написал: Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
То, что вы предлагаете, я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде. При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания. Ваше предложение легко реализуемо в QLua.
Старатель написал: Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua. Это примерно следующее: 1. Добавить в State поле счетчик. 2. При создании State счетчик = 0. 3. В цикле работы виртуальной машины Lua (исходник Lua 5.3.5 lvm.c) после текста: Instruction i; StkId ra;
добавить: if (++L-> счетчик > !00) { // 100 это конечно же надо задать константой -- L-> счетчик = 0; lua_unlock(L); lua_lock(L); }
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
После того как в QUIK 8.13.0.106 (с последними его исправлениями) синхронизация в QLua стала работать корректно (историю исправления можно посмотреть в ветке "Отладка QUIK 8.13" ), стабильность OS_Quesha, при работе в этой версии QUIK, стала такой же, как в старых версиях (до версии 8.5).
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Я хотел это оставить на потом, но исходя из того. что, похоже на то. что вы не исправимы: 1) вы не плохо разбираетесь в языке программирования Lua (это ваш плюс); 2) у вас много комплексов; и главный комплекс это проблема самодостаточности. когда вам хочется кого то унизить (но вы зря думаете. что я это подходящий объект0.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Артем написал: TGB , подразумевая что заспавнить вторую вм с аргументами это сложная и нетривиальная задача. Можно конечно изголяться чтобы например глобалки сами синхронизировались, но это вы уже сами себе Буратино.
Вы сами, понимаете, что написали? Все таки вы упорный. Зачем вы нарыватесь?
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: TGB , Начал было обрезать описание, но быстро утомился. В общем, вот он, мой "идеальный стиль" во всей красе:
Очень много букв Если о моем стиле "идеального стиля общения", то всего два пункта: 1) Не обижай тех, кто готов с тобой конструктивно взаимодействовать. 2) Не пропускай хамства, тех. кто на этом думает на этом по пиарится.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: я его даже назвал "идеальный стиль общения".
Я в этом не уверен. Посмотрите мои комментарии. Ни одного грубого слова, в том числе, и по отношению к вам. Но, хамство, иногда проявляемое в отношении меня, как мне кажется (но, возможно, я ошибаюсь) быстро исчезает. Для вас, как я это понимаю, общение на этом форуме ценная возможность. И мне кажется, что вам не стоит настраивать пользователей против себя.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: Ваш поросячий визг меня абсолютно не колышет:
Владимир, вы себя ведете на форуме очень грубо. Ангелов на форуме нет (это я отношу и к себе), но вы выделяетесь. Все таки мы находимся не в подворотне. На выподы против вас можно отвечать и по интеллигентнее.
Владимир написал: у меня целых три прерывания по таймеру
Все sleep, запускаемые в main, с любыми интервалами, будут выполняться последовательно. И мне стало интересно, что вы понимаете под прерыванием по таймеру (надеюсь это не аппаратные прерывания:smile: ). Поэтому, с этого места, пожалуйста, опишите поподробнее. Тела ваших циклов меня не интересуют, но схему их организации вы, наверное, смогли бы привести.
Тест синхронизации в QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) до сих пор не "падает". Для меня это означает, что в этой версии QUIK синхронизация в QLua реализована корректно.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: Lua-таблицы это, ваще-то, деревья.
Этим вы можете вносить смуту в не окрепшие умы Все-таки таблицы это таблицы. С помощью них можно строить кольца, сети. списки, стеки, очереди и, наконец, деревья.
Наверное, стоит пояснить, что же представляет собой контекст выполнения функции. Это все, от чего зависит ее результат. А это, в некоторых случаях не только явно задаваемые ее параметры, но и среда, в которой она выполняется. Например, результат файловой операции зависит не только от ее параметров, но и от состояния, в котором находится файл. Если не учитывать остальной контекст файловой операции, а только ее параметры, то можно бы было сказать, что эта операция неоднозначная (при одних и тех же параметра результат может быть разным). При учете всего контекста файловая операция однозначная. Если бы вы работали без операционной системы (ОС), то в контекст выполнения ваших функций входило бы и все то, чем занимается ОС (прерывания, параллельно работающие ядра ЦП и т.д). На самом деле, корректно реализованные средства разработки программ, в том числе и QLua, локализуют (уменьшают) тот контекст, от которого зависят пользовательские функции. В QLua, в той реализации как он сейчас есть и в том виде как его используют большинство пользователи (main и колбеки), по существу является однопоточным. А если это так, то, при корректной реализации QLua, проблемами параллелизма (в том числе атомарностью) можно было бы не озадачиваться.
Старатель написал: Volume[alltrade.price] = (Volume[alltrade.price] or 0) + alltrade.qty
1. Все операторы в QLua (включая функции, запускаемые в колбеках), в том числе с участием атомарных C-функций (выдающих однозначный результат в контексте их запуска), являются атомарными. 2. Взаимодействие колбеков с main подробно обсуждалось в ветке «Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номе-рами заявок и сделок» и Антон там достаточно детально это описал.
Старатель написал: if N >= 0 then N = N + 1Это атомарная операция?
Фрагмент if N >= 0 then N = N + 1 это "чистый" Lua, а при текущей реализации QLua все такие участки (и в мейне и в колбеках) выполняются под общей блокировкой. Поэтому это атомарная операция.
Итак, сегодня суббота. "Уронить" QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) мне не удалось. Ни с помощью моего трэшевого теста, ни добавлением к его работе частого запуска "тяжелого" скрипта с разнообразными операциями. Высказанные ранее мною предположения пока подтверждаются.
Владимир написал: TGB , Но не исчезнут они никогда!
Нужно исходить и того, что в более-менее объемной программе, всегда есть ошибка. И все же ошибки, на которые часто"наступают" пользователи, обычно, со временем вычищаются.
Цитата
Владимир написал: Не, я пока погожу. В конце концов, эта версия работает на компе моего друга. Вот и посмотрим, как она будет себя вести.
Если друг не обновит свою версию последними исправлениями, то ее стабильность не будет отличаться от вашей. Надо иметь ввиду, что проявление ошибок синхронизации существенно зависит от что реализуется в скрипте и возможно у вашего друга, вообще со стабильностью нет проблем.
Владимир написал: Снова Квик гавкнулся. Кажется, причина та же, что была и в прошлых глюках: конфликт утилит прорисовки таблиц и подачи транзакций.
Цитата
TGB написал: И все-таки, я бы на вашем месте перешел на QUIK 8.13.0.106 и еще бы сделал его обновление последними исправлениями.
Все версии до выше указанной (с обязательным обновлением после 13.04.21), по моим представлениям, с ошибкой синхронизации в QLua, проявляющей себя в виде похожем на то, что вы описываете. Для разных пользователей эти ошибки могут проявляться по разному.
Владимир написал: И у меня стойкое ощущение, что чем больше номер версии, тем глючнее содержимое.
Ну вы консерватор Регрес действительно временами (часто) наблюдается, но в основном, все-таки по принципу один шаг назад, а два вперед. Я понимаю, что вы сами с усами И все-таки, я бы на вашем месте перешел на QUIK 8.13.0.106 и еще бы сделал его обновление последними исправлениями.
Поддержка в ветке так и не проявилась. Но есть и хорошая новость. Тест (это OS_Quesha, запущенная в особо тяжелом режиме тестирования синхронизации в 16 потоках) в обновленном QUIK нормально работает до сих пор (16.04.21 15.28). Никаких аномалий типа утечки памяти, зацикливания и т.д. я в QUIK не обнаружил. Мои попытки «обрушить» QUIK многократными дополнительными запусками из OS_Quesha скрипта в котором есть файловые операции, отладочные операции, операции сереализации и восстановления таблиц, в том числе и _G, не удались. Для меня это означает, что в обновленном 13.04.21 QUIK 8.13.0.106 синхронизация в QLua, наконец, реализована корректно и QUIK, я думаю, стал более стабильным. Похоже, эта эпопея , начавшаяся для меня в мае 2020г. с посылки поддержке первого письма с дампом и с текстом о том, что в QLua 8.5 есть ошибка синхронизации, завершилась.
Anton написал: У вас, например, я не увидел DeleteCriticalSection, потому ли, что вы не нашли, куда бы ее приткнуть? Там есть куда, см. luai_userstateopen, luai_userstateclose, luai_userstatefree. Аналогичные макросы есть для потоков. Хайли лайкли косяк (был?) где-то в этих местах, что-то удаляется слишком рано. Ваш хост даже не пытается эту сторону промоделировать, чего же ему падать-то.
Чем меньше дергаешься, тем реже падаешь Я не ставлю задачу что-то моделировать. Первая задача при разработке любой программы это обеспечение правильности ее работы. В своих разработках программ придерживаюсь некоторых принципов. Вот два из этого списка: 1) Не делай лишней работы. 2) Все, что можно реализуй статически. ----- Если по существу обсуждаемого, то я жду субботы. Если мой тест, запущенный в обновленном QUIK 8.13.0.106, не уронит его до субботы, то для меня это будет признак того, что в обновленном QUIK обсуждаемая синхронизация, скорее всего, наконец, реализована корректно.
Александр М написал: Не совсем понял Ваш ответ. После обновления на 8.3.0.106 на родной (НЕ измененной) библиотеке lua проблемы исчезли?
После упомянутого мною обновления QUIK 8.13.0.106, скорости на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. Для меня это косвенный признак того, что, в обновленном QUIK 8.13.0.106 синхронизация могла быть реализована, как на моем стенде, то есть, по моему мнению, правильно. Для подтверждения этой гипотезы я в новой версии QUIK запустил 13.04.21 вечером свой тест, который не обновленную версию QUIK "ронял" гарантированно в пределах чуть более одних суток. Сейчас 15.04.21 17.56 тест идет нормально и установлен новый продолжительности его работы. При этом, в обновленном QUIK 8.13.0.106 я не наблюдаю никаких проблем. Если тест не "уронит" QUIK до субботы, то, наверное, можно будет, с большим основанием, предположить, что в обновленном QUIK 8.13.0.106 наблюдаемые мною ранее ситуации устранены, то есть синхронизация реализована корректно.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: Что такое "нагружает управление памятью" я не понял.
Попробую объяснить. Дело в том, что при программировании на Lua вам совсем не надо управлять памятью (ее запросом/возвратом, контролем за всем этим - большой геморрой при разработке программ). В Lua это делается автоматически ("под капотом"). Тем не менее это все делается за счет вычислительных ресурсов пользователя (время ЦП, память и т.д.). Существуют ситуации, в которых вроде бы на безобидных операциях в циклах, например: s = s .. s1 расход вычислительных ресурсов может резко увеличивается. На каждом выполнении s = s .. s1 в невидимом для вас управлении памятью выполняется по меньшей мере запрос памяти под новый размер s и отказ от памяти s до начала операции. Запрос памяти это достаточно затратная операция, как-то зависящая от размера памяти. Для отказа от памяти в Lua, не считая некоторых случаев, ничего специально не выполняется. Если на некоторую область памяти нет ссылок из существующих в текущий момент объектов скрипта, то она считается неиспользуемой (мусорной). Но чтобы мусор не накапливался (это никем не используемая память ПК), в Lua время от времени запускается сборка мусора (одна из наиболее сложных операций, выполняемых "под капотом" Lua). Сборка мусора тоже использует вычислительные ресурсы скрипта.
Вы дали ответ только на два мои вопроса (а их всего четыре). Было бы интересно почитать ваши версии ответов на остальные мои два вопроса. Кстати, по поводу возможной оптимизации синхронизации в QLua, вы можете посмотреть мой комментарий в ветке «Средства разработки многопоточных скриптов в QUIK».
Anton написал: Квик перехватывает создание стейта для скрипта (для этого в луа есть соответствующие макросы под переопределение), прицепляет к стейту дополнительную структуру и создает критическую секцию в этой структуре, свою для каждого скрипта (именно поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет). ......
Вы это пишите как разработчик QUIK или как любитель?
Цитата
Anton написал: поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет
Вы прочитали это?:
Цитата
TGB написал: На этом стенде, точно та же моя тестовая программа (16 интенсивно нагруженных потоков в одном Lua-скрипте), работает непрерывно неделями, и я не могу дождаться, когда же она, наконец, упадет.
----- Могу так же поздравить себя с тем, что после упомянутого мною обновления QUIK 8.13.0.106 скорости на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. И куда же делась "затейливость", обеспечивающая высокую скорость QUIK? Причем, в обновленном QUIK мой тест, запущенный вечером 13.04.21 пока работает без проблем. Если он не "обрушит" обновленную версию QUIK до субботы, то скорее всего он дотянет и до следующей субботы. А если это произойдет, то кому что-то будет непонятно?
Александр Волфовиц написал: TGB ,а как квик может обновиться "неожиданно для вас"? Появляется оповещение "На сервере появилась новая версия, обновить?" Если нажмёте кнопочку "нет" , то будете работать на старой версии.
"Неожиданно для меня" это фигура речи. Конечно же, мною были нажаты все необходимые кнопки.
Евгений написал: Придется оправдаться за неисправленные ошибки, лучше не читать
)
Читать не читают, но что характерно : 1. Мой комментарий был написан 10.04.21. 2. А вчера вечером (13.04.21) мой QUIK 8.13.0.106 совершенно неожиданно для меня автоматически обновился. Возможно это простое совпадение, но на всякий случай я запустил в нем свой тест (с подключением к серверу. Если он не "обрушит" обновленную версию QUIK в течении недели (до 20.04.21) то, наверное, разработчиков QUIK можно будет поздравить. При этом я не исключаю, что действительно поддержка ветку не читает (и особенно, длинные тексты )
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Об оптимизации синхронизации в QLua. Не затрагивая существующей архитектуры обработки колбеков в QUIK, можно оптимизировать синхронизацию многопоточности QLua. Дело в том, что при синхронизации по умолчанию, как это, похоже, реализовано в существующей QLua, все вызовы C-функций имеют следующий общий вид: unlock ….; <Вызов C-функции>; lock ……; В операциях unlock и lock возможны преключения потоков. То есть, это ресурсоемкие операции. Если вызываемая C-функция выполняется быстро, как напри-мер, многие математические функции, то при существующей синхронизации, коэффициент полезного использования времени ЦП может быть очень низким : <Время выполнения C-функция > / (< Время выполнения unlock > + < Время вы-полнения lock >). Понятно, что в циклах QLua с обращением к коротким C-функциям QLua занимается в основном синхронизацией. Идея оптимизации состоит в том, чтобы у пользователя была динамическая возможность задания/отмены C-функций, которые вызываются без выше описанной синхронизации (ввести особый список). Сделать эффективную реализацию выше описанного несложно. Чтобы гарантировать обязательную «щель» для запуска колбеков, из списка допустимых C-функций, описанных в предыдущем абзаце операций, имеет смысл исключить sleep, а возможно, и еще какие-то функции обеспечения задержек по времени и файловые операции. Существенным положительным моментом описанной оптимизации является то, что она никак не затрагивает тех пользователей, которые не будут ее использовать. При ее применении, коэффициент полезного использования времени ЦП: 1) для функций из особого списка: <Время выполнения C-функция > / < Время анализа особого списка> 2) для обычных функций: <Время выполнения C-функция > / (< Время анализа особого списка> + < Время выполнения unlock > + < Время выполнения lock> ). При качественной реализации оптимизации можно добиться того, чтобы < Время анализа особого списка> было существенно меньше, чем (< Время выполнения unlock > + < Время выполнения lock>).
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Незнайка написал: Правда, не знаю, для каких практических задач может потребоваться склейка огромного количества строк.
Когда вы занимаетесь своей конкретной задачей, вам действительно, решать задачу склейки огромного количества строк может быть никогда не придется. Но если вы разрабатываете программный инструмент для достаточно широкого круга пользователей, вам придется учесть, что у кого то такая задача может возникнуть. Поэтому у меня (где то это уже отмечалось) в системе есть специальная C-функция сбора строки в один проход практически без нагрузки на управление автоматической памятью Lua. Чтобы использовать эту функцию непосредственно в выложенном мною модуле, пришлось бы подключать мой C-пакет.
Цитата
Незнайка написал: На выходе вместо Lua-таблицы получается какая-то нечитаемая "каша". Странный выбор... или у нас разное понимание понятия "сереализация". Чем обусловлен выбор такого формата? Он ведь труден для восприятия.
При сереализации не стоит задача получить строку в удобно читаемом формате. Для этого есть функция dump_tbl, где выделяются все отступы и т.д. Для задачи сереализации достаточно того, чтобы результат str_to_tbl (<строка-результат из функции tbl_to_str (<Таблица>....) был <Таблица>. В принципе, не очень сложно, так модифицировать, выложенный мною модуль, чтобы формат сереализованной таблицы был в виде { [] = { ........ } } но это уже не принципиально и я не вижу смысла в том, чтобы этим заморачивться. Строка-результат сереализации предназначена не для изучения ее пользователем, а для подачи в функцию восстановления таблицы.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Новые версии QUIK стали заметно устойчивее, чем это было в мае 2020г. Однако, нечасто, но в течении двух-трех суток версия QUIK 8.13, в которой запущен мой тест синхронизации в QLua, без подключения к серверу, зависает с выдачей сообщения: Critical error ACCESS_VIOLATION (Критическая ошибка НАРУШЕНИЕ ДОСТУПА). Дампы при этом не сбрасываются. Многое указывает на то, что в QUIK 8.13 есть ошибка синхронизации (и все-таки земля вертится ). Попробую это обосновать. 1. Ошибка «error ACCESS_VIOLATION» в QUIK 8.13 возникает в разных местах моей тестовой программы, и в разные моменты времени. 2. Я собрал из исходников Lua 5.3.5 вариант исполняемого кода Lua (свой стенд), в котором допустимы обращения к VM-Lua из разных потоков. На этом стенде, точно та же моя тестовая программа (16 интенсивно нагруженных потоков в одном Lua-скрипте), работает непрерывно неделями, и я не могу дождаться, когда же она, наконец, упадет. 3. Я провел следующий эксперимент: 1) Запустил на выполнение программу на «чистом» Lua (без обращения к С-кодам, где отсутствует синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось одинаковым. 2) Запустил на выполнении программу на «смешанном» Lua (с обращениями к С-кодам, где должна работать синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось разным. Причем на моем стенде ~ 1, 4 раза больше. Вопрос: в QUIK 8.13 сумели, как то сильно оптимизировать синхронизацию доступа к VM-Lua из разных потоков? Я думаю, это вряд ли. Скорее всего, есть ошибка в реализации синхронизации в QLua 8.13.
В своем стенде, для синхронизации доступа к VM-Lua, я использую критическую секцию, и далее я приведу все места в исходном тексте Lua 5.3.5, где мною были внесены изменения для обеспечения синхронизации. Обращаю ваше внимание на то, что при синхронизации должен использоваться общий объект синхронизации. Возможно?, место синхронизации в QLua было выбрано неудачно. ----- Мои изменения (для обеспечения синхронизации) в исходном коде Lua 5.3.5 приведены в следующем виде: 1) № изменения 2) <Имя файла исходника> 3) <Текст исходника, позволяющий определить место после которого внесено изменение> 4) <Текст изменения> -------------------------------------------------------------------------------- 1. Изменение № 1 Файл: ldo.c Место: #include "ldo.h" Добавление: #include "DbgHelp.h" #pragma comment(lib, "Dbghelp.lib") void lua_lock_MT(lua_State *L) { global_State *g = G(L); EnterCriticalSection(&g->Глобальная_критическая_секция); }
4. Изменение № 4 Файл: limits.h Место: /* ** macros that are executed whenever program enters the Lua core ** ('lua_lock') and leaves the core ('lua_unlock') */ Добавление: #if !defined(lua_lock) #define lua_lock(L) lua_lock_MT(L) #define lua_unlock(L) lua_unlock_MT(L) #endif ----- 5. Изменение № 5 Файл: luaconf.h Место: ** the libraries, you may want to use the following definition (define ** LUA_BUILD_AS_DLL to get it). */ Добавление: #define LUA_BUILD_AS_DLL ----- 6. Изменение № 6 Файл: lstate.c Место: g->gcstepmul = LUAI_GCMUL; Добавление: InitializeCriticalSection(&g->Глобальная_критическая_секция); ----- 6. Изменение № 7 Файл: lstate.h Место: TString *strcache[STRCACHE_N][STRCACHE_M]; /* cache for strings in API */ Добавление: CRITICAL_SECTION Глобальная_критическая_секция;
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Конструктивной частью нашей (во многом, содержательной) дискуссии с Артемом я считаю, для себя, реализацию модифицированного модуля сереализации Lua-таблиц. Этот модуль создан в соответствии с вариантом решения, который был кратко описан мною в комментарии № 164. Замечу, что мои комментарии в ходе дискуссии с Артемом, особенно в части размеров кода, относились к функциональности, выложенного им модуля. Функциональность модифицированного модуля, а также эффективность выполнения в нем сереализации и восстановления таблиц, иные. --- Код модуля выложен в конце данного комментария. ----- В простом варианте восстановления сереализованной таблицы (в том числе и после перезапуска скрипта), когда контекст (определение приведено в описании модуля) ее восстановления не отличается от контекста сереализации, все просто: -- Сереализация таблицы -- <Строка образа (! в случае отсутствия 3-го параметра)> = tbl_to_str (<Таблица> [, <Путь файла сохранения образа или вид результата (0 | 1 байт-код или строка-скрипт)> [ ,<Контекст сереализации>]])
………… !! Здесь может быть и перезапуск скрипта --
-- Полное восстановление таблицы (со всеми ее значениями без исключения ) -- <Таблица)> = str_to_tbl (<Сохраненный где образ - результат функции tbl_to_str > [,<Контекст сереализации>]) ------ Более сложный вариант использования модуля (при различии контекста восстановления таблицы от контекста сереализации) приведен далее, в его описа-нии. -------------------------------------------- В описании модуля значения типов function, userdata и thread называются ссылочными значениями. Сереализуемая таблица, в описании, обозначена именем <T>. Внутренним именем ссылочного значения называется результат функции internal_name (<Cсылочное значение>), определенной в модуле. Составное имя имеет вид адреса поля в таблице: <T1>.<T2>…..<Tn>.<Поле таблицы Tn> Под контекстом выполнения (сереализации, восстановления) далее описываемых функций понимается список доступных им, в момент их выполнения, ссылочных значений, на которые есть ссылки из <T>. -- Описание модуля. 1. Существенных отличий данного модуля, от выложенного Артемом, три: 1) Формирование таблицы ссылочных значений <T> в формате, обеспечивающем, полное восстановление <T> (в том числе, с учетом ее локаль-ного окружения) в контексте ее сереализации из образа, сохраненного в файле (в том числе и после перезапуска скрипта). Кроме того, обеспечен удобный контроль и коррекция результата восстановления <T> в контексте, отличном от контекста ее сереализации. 2) Результатом сереализации таблицы <T> является Lua-скрипт восстановления этой таблицы (в виде байт-кода или исходного кода Lua), со-держащий в себе две таблицы ссылочных значений (контекста и <T>), 3) На таблице _G (в моем скрипте) время выполнения сереализации в дан-ном модуле в ~1,5 раза меньше, чем в сравниваемом модуле, а время восстановления _G меньше в ~ в восемьнадцать раз (мои конкретные числа данного модуля для _G ~ 8000 элементов: сереализация ~ 55 млсек., восстановление ~ 2 млсек.). С уменьшением сереализуемой таб-лицы, описанные выше времена, уменьшаются почти линейно.
2. В модуле доступны пять функций: 1) Сереализация таблицы: tbl_to_str (<T> [, <Признак выдачи результата в виде байт-кода или строки-скрипта 0|1> | <Путь файла записи строки-скрипта > [ ,<Контекст сереализации: таблица или функция >] ]) Результат в зависимости от входных параметров: <байт-код восстановления <T> | <Строка-скрипт восстановления <T>> | <Запись строки-скрипта в файл с заданным путем>.
2) Восстановление таблицы: str_to_tbl (< Байт-код скрипта для восстановления <T>, либо строка-скрипт>[ , <Контекст восстановления: таблица или функция >]) Результаты. Их может быть один или три (если есть висячие ссылочные значения): 1-й - восстановленная таблица с пометкой висячих ссылок, если такие существуют в виде составных имен в контексте сереализации. Второй и третий – nil, если висячих ссылок нет или две таблицы: - таблица висячих ссылок с указанием составных имен-адресов в кон-тексте сереализации; - таблица висячих ссылок с указанием составных имен –адресов в <T>. Эти данные могут быть основой для восстановление таких ссылок.
3) Формирование служебных таблиц, используемых в функциях tbl_to_str и str_to_tbl: creating_link_tables (<Контекст выполнения функций tbl_to_str и str_to_tbl > [, <Признак обновления существующего контекста = 1>]) Первый параметр либо таблица (например, _G), либо пользователь-ская функция создания таблиц контекста (по образцу аналогично тому, как это делается в creating_link_tables). В случае функции, при создании | изменении контекста, вместо creating_link_tables запускается пользовательская функция. По умолчанию контекстом является _G. Результаты функции две таблицы формируемые в ней.
5) Печать любой таблицы Lua в виде удобном для анализа, с указанием уровней вложенности всех ее элементов: dump_tbl (<Таблица>, <Символ отступов для выделения вложенности эле-ментов таблицы>, <Уровень раскрываемых вложенностей таблицы (если 0, то показывается все > [, <Вид выдачи результата: false – таблица (по умол-чанию); true - строка> [, < Таблица имен элементов (задаваемых в ключах) , не разворачиваемых далее >]]). ---- В квадратных скобках при описании всех функций указаны необязательные параметры.
3. При сереализации <T> ее ссылочные значения не сохраняются, но при восстановлении <T>, ссылки на ее ссылочные значения, разрешаются (устанавливают-ся на значения) в контексте ее восстановления. Если контекст, в момент восстановления <T>, такой же (в части всех ее ссылочных значений), как и в момент ее сереализации, то ничего кроме запуска функции str_to_tbl с единственным параметром-результатом, полученным из функции tbl_to_str не требуется; в этом случае таблица <T> будет восстановлена полностью (со всеми ее значениями, включая ссылочные). При отличии контекста восстановления от контекста сереализации таблицы в момент ее восстановления, некоторые ссылки могут оказаться «висячими». Для возможности восстановления висячих ссылок функция str_to_tbl выдает дополнительно к восстановленной <T> c указанием в ней висячих ссылок, две таблицы описания таких ссылок в удобном для анализа виде.
4. В функции str_to_tbl выполняется автоматический контроль разрешимости ссылок <T> на ее ссылочные значения. Выполняемый контроль частичный, в том смысле, что если он не проходит, то это значит, что контекст восстановления <T> точно отличен от контекста ее сереализации. Если же этот контроль проходит, то это означает, что имеется всего лишь полное совпадение сформированных имен ссылочных значений <T>, с именами контекста ее восстановления. При этом может оказаться (! только при отличии контекста восстановления <T> от контекста сереализации), что какая то часть восстановленных ссылочных значений не валидна (восстановленное значение отличается от сереализованного). Вероятность появления невалидности значений, скорее всего, будет очень малой, но не 0. Это надо учитывать и, для случая отличия контекста восстановления от контекста сереализации, желательно выполнять дополнительный контроль а, при необходимости и исправление. ---------- Модуль можно использовать свободно, а при распространении, желательна ссылка на меня. Сообщения об обнаруженных ошибках, замечания и вопросы будут мне интересны. --- Одним из вариантов использования данного модуля может быть реализация контрольной точки, обеспечивающей продолжение выполнения любой цикличе-ской функции (аналога функции main в QLua) после ее перезапуска (по любой причине). При этом, для эффективности контрольной точки (уменьшения сохра-няемых данных) а также защищенности данных функции, можно реализовывать (по крайней мере, начиная с версии 5.3), с помощью _ENV, дополнительно к ее локальным переменным, собственное окружение функции, хранящее только ис-пользуемые в ней, ее сереализуемые значения. Такой вариант реализован мною в OS_Quesha для некоторых ее системных циклических функций.
Код модуля:
Код
-- Модуль сериализации таблиц. Автор TGB ---
---------------------------
--- Быстрая сборка строки из массива строк ----
-- Не обязательный параметр pr = false - строка собирается в прямом порядке (от начала массива к концу); true - строка собирается в обратном порядке --
local function m_str_to_str_fast ( m_str , pr)
if type (m_str) ~= 'table' then return nil, ' ! Ошибка. Первый параметр m_str_to_str_fast не таблица ***' end
local const_mod = 10, m_str_tm
local mod, N , NN
local N_mod, i_mod
----
if pr then
m_str_tm = {}
NN = #m_str
for i = NN, 1, -1 do m_str_tm [NN - i +1] = m_str [i] end
m_str = m_str_tm; m_str_tm = {}
end
while 1 do
m_str_tm = {}
mod, N, NN = #m_str % const_mod, math.floor (#m_str / const_mod), #m_str
N_mod = N * const_mod
for i = 1, N do
i_mod = (i -1)*const_mod
m_str_tm [i] = m_str [ i_mod + 1] .. m_str[ i_mod + 2] .. m_str [ i_mod + 3] .. m_str [ i_mod + 4] .. m_str [ i_mod + 5]
.. m_str [ i_mod + 6] .. m_str [ i_mod + 7] .. m_str [ i_mod + 8] .. m_str [ i_mod + 9] .. m_str [ i_mod + const_mod]
end
if mod > 0 then
N = N + 1; m_str_tm [N] = ''
for i = 1, mod do m_str_tm [N] = m_str_tm [N] .. m_str [N_mod + i] end
end
----
if #m_str_tm > 1 then
m_str = m_str_tm
else return m_str_tm [1]
end
end
end
----------------------------------
----------------------------------
--- Вывод произвольной таблицы в виде таблицы-массива строк (либо в виде строки) ------
------ Параметры:
-- 1) t - таблица (выводятся все вложения до limit);
-- 2) i - строка формирования отступа при выводе вложений (например, ' ')
---- 3) limit - уровень вложенности до которого просматривается таблица (если = 0, то все уровни)-----
---- 4) (не обязательный) <Вид выдачи резкльтата: false – таблица (по умол-чанию); true - строка>
---- 5) (не обязательный) <Таблица имен элементов (задаваемых в ключах) , не разворачиваемых далее >
--- ! Результат: таблица строк: структура со значениями таблицы t (текстовая сортировка по возрастанию индексов таблиц) либо строка,
--- в зависимости от параметра pr-----
--- !! Элемент таблицы [1] - заголовок таблицы. Остальные элементы - строковые представления структуры таблицы t
--- с дополнительными служебными описаниями вложенных в t таблиц.
local function dump_tbl (t, i, limit, pr, list)
if type(t) ~= 'table' then
if pr then return ' Первый параметр t не таблица. Результат: ' .. tostring(t) end
return nil, '! Ошибка. Первый параметр t не таблица'
end
list = list or {}
if type(list) ~= 'table' then
return nil, '! Ошибка. Параметр list не таблица'
end
limit = limit or 0
local tbl = {}; --- для результата ----
tbl[#tbl +1] = '===== Таблица (текстовая сортировка по возрастанию индексов таблиц): ' .. tostring(t)
.. ' \n ! Количество выводимых уровней вложенности (если = 0, то выводятся все) = ' .. limit .. '\n'
local seen={} -- просмотренные --
local Level = 0
------------------------------------------
local function dump(t,i, nm) -----
nm = nm or 'T'
if seen [t] then
return seen [t]
end
------
seen [t] = nm --- !
local t_v, t_k, nm_tm
Level = Level +1 --- Уровень вложенности таблицы ----
--- Обработка метатаблицы ----
local mt = debug.getmetatable ( t )
if mt then
nm_tm = seen[mt]
if nm_tm then
tbl[#tbl +1] = i .. 'Для таблицы ' .. nm .. ' cсылка на существующую метатаблицу -> ' .. nm_tm .. '\n'
else
nm_tm = tostring(mt)
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Содержимое метатаблицы ### : ' .. nm_tm .. '\n'
dump(mt, i..'\t', nm_tm)
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Конец метатаблицы ## ' .. nm_tm .. '\n'
end
end
if next (t) == nil then ---- Таблица пустая ---
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' Таблица: ' .. nm .. ' пустая ### '.. '\n'
Level = Level - 1
return ''
end
local s={} --- массив хранение имен ключей (строк) для сортировки ---
local ss={} -- массив для хранения самих ключей --
local n=0
local ks=0
for k, v in next, t do
ks = tostring(k)
n=n+1
s[n] = ks
ss[ks] = k
end
table.sort(s)
for k,v in ipairs(s) do ---
t_k = ss [v] -- ключ записи в t
t_v=t [t_k] -- значение записи в t
if Level < limit or limit == 0 then
if type(t_k) == 'table' then --- Обработка ключа-таблицы ---
nm_tm = seen[t_k]
if nm_tm then
tbl[#tbl +1] = i .. '[ ' .. tostring(t_k) .. ' - cсылка на существующую таблицу-ключ -> ' .. nm_tm .. ']' .. '\n'
else
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Содержимое ключа-таблица $$ : ' .. v .. '\n'
dump(t_k, i..'\t', tostring(t_k))
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Конец ключа-таблицы $$ ' .. v .. '\n'
end
end
if list [v] then
if type(t_v) == 'table' then
tbl[#tbl +1] = i .. '[' .. v .. '] (' .. type(t_v) .. ') = ' .. tostring(t_v) .. ' | Терминальная таблица (в печати задано далее не разворачивать) ### \n'
else
tbl[#tbl +1] = i .. '[' .. v .. '] (' .. type(t_v) .. ') = ' .. tostring(t_v) .. '\n'
end
else
tbl[#tbl +1] = i .. '[' .. v .. '] (' .. type(t_v) .. ') = ' .. tostring(t_v) .. '\n'
if type(t_v) == 'table' then --- Обработка таблицы ----
nm_tm = seen [ t_v]
if nm_tm then
tbl[#tbl +1] = i .. '[' .. v .. '] ссылка на существующую таблицу -> ' .. nm_tm .. '\n'
else
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Содержимое таблицы : ' .. v .. '\n'
dump(t_v, i..'\t', tostring(t_k))
tbl[#tbl +1] = i .. 'Вложенность: ' .. Level .. ' === Конец таблицы ' .. v .. '\n'
end
end
end
end
end
Level = Level - 1
return ''
end
--------------
dump(t,i, tostring(t))
if pr then --- Выдача результата в виде строки
return m_str_to_str_fast ( tbl)
else return tbl --- Выдача результата в виде массива строк
end
end
-------------------------------- Общие данные модуля -----------------------------------------
--- 1. Для выделения строк используется скобки [[ ]] и поэтому внутри них не надо никаких преобразований (типа замены \ на \\ и т.д).
-- 2. В выдаваемых стоках для удобства анализа, места, на которые надо обращать внимание в первую очередь выделены символом ###.
----
local aliases_cont = { } --- [ <Внутреннее имя ссылочного значения> ] = <Внешнее имя ссылочного значения в контексте>
local aliases_v_cont = { } --- [ <Внешнее имя ссылочного значения в контексте> ] = <Ссылочное значение в контексте>
local wo_creator -- Призак где сформирована таблицы
local tbl_cont = _G --- Контекст по умолчанию ---
local context_tbl = 'CONT' -- Имя, присвоенное контексту
-----
----- Формирование внутренних имен --
local function internal_name ( s )
return tostring ( s ):gsub ( ': ', '' )
end
----------------------------------------------
-- Параметры
-- 1) 1-й параметр либо таблица, либо пользовательская функция соз-дания таблиц контекста (по образцу аналогично тому,
-- как это делается в creating_link_tables). В случае функции, при создании, изменении контек-стэтом вместо creating_link_tables
-- запускается пользовательская функ-ция.
-- 2) необязательный, если 1, то принудительное обновление таблиц формируемых в ней
-- Результаты : две таблицы формируемые в ней.
---
local function creating_link_tables (context, pr)
if type(context) == 'function' then
wo_creator = 'no creating_link_tables'
local cont, v_cont = context (pr) --- context должен выдавать два результата ---
if cont then aliases_cont, aliases_v_cont = cont, v_cont end
return aliases_cont, aliases_v_cont
end
------
if pr then aliases_cont, aliases_v_cont = {}, {} end -- Обновление общих данных ---
if next (aliases_cont) ~= nil and not pr then return end ----
if type(context) ~= 'table' then context = tbl_cont end
----
wo_creator = 'creating_link_tables'
local path = '###: ' .. context_tbl
----------------------------
local function cr_link_tables (item, path, seen)
seen = seen or { }
path = path or context_tbl
local mt
if item == nil or seen [ item ] ~= nil then
return
elseif type ( item ) == 'table' then
seen [ item ] = true
-- Обработка метатаблицы (если есть в item)---
mt = debug.getmetatable ( item )
if type ( mt ) == 'table' then cr_link_tables (mt, path .. '.' .. '.metatable###', seen ) end
---
local path_tm, kl_tm, k_tm
for k, v in pairs ( item ) do
if type ( v ) == 'table' then ---- таблица-значение --
cr_link_tables (v, path .. '.' .. tostring ( k ), seen )
else
if not (type(v) == 'number' or type(v) == 'boolean' or type(v) == 'string') then
if type(k) == 'string' then kl_tm = '.' .. tostring ( k ) else kl_tm = '[' .. tostring ( k ) .. '] ' end
path_tm = path .. kl_tm
k_tm = internal_name (v)
if not aliases_cont [k_tm] then aliases_cont [k_tm] = path_tm end --- ### ?? возможна перезапись ---
aliases_v_cont [ path_tm ] = v
end
end
----
if type ( k) == 'table' then ---- таблица-ключ --
cr_link_tables (k, path ..'.' .. tostring ( k ), seen )
else
if not (type(k) == 'number' or type(k) == 'boolean' or type(k) == 'string') then
if type(k) == 'string' then kl_tm = '.' .. tostring ( k ) else kl_tm = '[' .. tostring ( k ) .. '] ' end
path_tm = '### ключ: ' .. path .. kl_tm
k_tm = internal_name (k)
if not aliases_cont [k_tm] then aliases_cont [k_tm] = path_tm end --- ### ?? возможна перезапись ---
aliases_v_cont [ path_tm] = k
end
end
end
end
end
cr_link_tables (context, path)
-- MessageDb ( 1, 1, 'Скрипт', ' Финальные проверки. creating_link_tables - aliases_v_cont : \n' .. dump_str ( aliases_v_cont , ' ', 0))
---[[
-- Обработка внешних локальных ссылочных данных контекста ---
local level = 2, ii, name, value
local k_tm, path_tm
while 1 do
if debug.getinfo (level, 'n') then
ii = 1
while 1 do
name, value = debug.getlocal(level, ii)
if name then
if not ( type(value) == 'table' or type(value) == 'number' or type(value) == 'boolean' or type(value) == 'string') then
k_tm = internal_name ( value)
path_tm = '###: LOC.' .. tostring (level) .. '.' .. tostring (ii) .. '.' .. name
if not aliases_cont [k_tm] then aliases_cont [k_tm] = path_tm end --- ### ?? возможна перезапись ---
-- aliases_cont [k_tm] = path_tm
aliases_v_cont [ path_tm ] = value
end
else
break
end
ii = ii + 1
end
else
break
end
level = level + 1
end
----------------------------
---]]
return aliases_cont, aliases_v_cont
end
------------------------------------------------------------
-- Функция создает байт-код либо строку-скрипт Lua, при запуске которого восстанавливается таблица t.
-- В эту же строку в конец добавляется две таблицы ссылочных значений
---- Параметры:
-- 1. t - сереализуемая таблица
-- 2. ph_f - (не обязательный) путь файл сброса строки-скрипта либо признак (0 | 1) выдачи образа в виде (байт-кода | строки - скрипта)
-- 3. context - - (не обязательный) контекст
-- Результат в зависимости от входных параметров: <Функция Lua > (один тараметр) | <Строка-скрипт> (второй параметр = 1)
-- | <Запись строки-скрипта в файл> (второй параметр строка путь к файлу)
local function tbl_to_str ( t, ph_f, context)
----Контроль параметров ---
if type ( t ) ~= 'table' then
return nil, '!! Ошибка. Второй параметр не таблица.'
end
ph_f = ph_f or 0
local f_t
if type(ph_f) == 'string' then
f_t = io.open( ph_f, 'w')
if type(f_t ) ~= 'userdata' then return nil, '!! Ошибка при открытии файла' end
end
creating_link_tables (context)
------
local name_alias = 'alias' --- для формирования команд с учетом alias ----
local env_t = context_tbl
local env = env_t .. '.'
local path = '###: TBL'
local t_str = {} --- для сбора строк
---
local name_t, context_t = {}, {}
-----------------------------------------
local function tbl_str ( t, path, seen )
seen = seen or { }
if seen [ t ] then
return false, env .. internal_name ( t )
else seen [ t ] = 0 end
-------
local n_t, mt = env .. internal_name ( t ), debug.getmetatable ( t )
t_str [ #t_str + 1 ] = n_t .. ' = {} --- создание таблицы: ' .. n_t .. ' -- \n'
local n_tt, n_kt, n_vt , st, nm_t, path_t
for k, v in pairs ( t ) do
if (type(v) == 'number' or type(v) == 'boolean' or type(v) == 'string') then -- Простое значение --
if type(v) == 'string' then
n_vt = '[[' .. v .. ']]'
else n_vt = tostring (v)
end
elseif type ( v ) == 'table' then --- Таблица-значение --
n_vt = internal_name (k)
t_str[ #t_str + 1 ] = ' --- ' .. n_vt .. ' - значение-таблица (начало) @ \n'
st, n_vt = tbl_str ( v, path .. '.' .. n_vt, seen )
if not st then t_str [ #t_str + 1 ] = ' -- Таблица ' .. n_vt .. ' была создана ранее ----\n ' end
t_str[ #t_str + 1 ] = ' --- ' .. n_vt .. ' - [' .. internal_name (v) .. '] значение-таблица (конец) @ \n'
else --- Ссылочное значение ---
nm_t = internal_name (v)
path_t = path .. '.' .. internal_name (k)
context_t [nm_t] = aliases_cont [nm_t]
if name_t [nm_t] then
name_t [nm_t] = name_t [nm_t] .. ' | ' .. path_t
else name_t [nm_t] = path_t
end
n_vt = name_alias .. '[ [[' .. nm_t .. ']] ]' or '### err'
end
if (type(k) == 'number' or type(k) == 'boolean' or type(k) == 'string') then -- Простое значение --
if type(k) == 'string' then
n_kt = '[[' .. k .. ']]'
else n_kt = tostring (k)
end
elseif type ( k ) == 'table' then --- Таблица-ключ ---
n_kt = internal_name (k)
t_str[ #t_str + 1 ] = ' --- ' .. n_kt .. ' - ключ-таблица (начало) @ \n'
st, n_kt = tbl_str ( k, path .. '.' .. n_kt, seen ) --- Создание таблицы ключа и ее 'скобок' ----
if not st then t_str[ #t_str + 1 ] = ' -- Таблица ' .. internal_name ( k ) .. ' была создана ранее ----\n ' end
t_str[ #t_str + 1 ] = ' --- ' .. n_kt .. ' - [' .. internal_name (k) .. '] ключ таблица (конец) @ \n' ---
else --- Ссылочное значение ключа ---
nm_t = internal_name (k)
path_t = path .. '.' .. nm_t
context_t [nm_t] = aliases_cont [nm_t]
name_t [nm_t] = path .. '.' .. nm_t .. '.ключ###'
if name_t [nm_t] then
name_t [nm_t] = name_t [nm_t] .. ' | ' .. path_t
else name_t [nm_t] = path_t
end
n_kt = name_alias .. '[ [[' .. nm_t .. ']] ]' or '### err'
end
n_tt = env .. internal_name ( t )
t_str[ #t_str + 1 ] = n_tt .. ' [ ' .. n_kt .. ' ] = ' .. n_vt .. ' \n'
end
if mt then -- создание и подключение метатаблицы в конце прохода по таблице с тем, чтобы она не мешала заполнять таблицу. Иначе пришлось бы использовать rawset ---
t_str[ #t_str + 1 ] = ' --- Создание метатаблицы --- \n'
st, mt = tbl_str ( mt, path .. '.' .. internal_name (mt), seen )
if not st then t_str[ #t_str + 1 ] = '-- Метатаблица ' .. mt .. ' была создана ранее ----\n ' end
t_str[ #t_str + 1 ] = 'debug.setmetatable ( ' .. n_t .. ', ' .. mt .. ' ) --- подключение метатаблицы ' .. mt .. ' --- \n'
end
return true, n_t --- 1 - й результат - признак создания таблицы
end
---------------------
tbl_str (t, path)
--- Формирование фрагментов скрипта -----
local scr1 = 'local '.. name_alias .. ' = {...}; ' .. name_alias .. ' = ' .. name_alias .. ' [1] ; local ' .. env_t .. ' = {} \n'
.. '\n if type(' .. name_alias .. ') == "table" then \n'
local scr2 = '\n return ' .. t_str[1]: match ( '(%S*)') .. '\n else \n--- Две таблицы внутренних имен ссылочных значений : \n '
.. ' -- 1) name_cont [<Внутреннее имя ссылочного значения >] = ###: <Составное имя значения в контексте сереализации таблицы> \n'
.. ' -- 2) name_t [<Внутреннее имя ссылочного значения >] = ###: <Список составных имен таблицы, ссылающиеся на значение > \n'
.. '--- ! Составные имена таблицы (если их неколько) разделены символом | . \n'
local scr3 = '\n local name_cont = { '
local scr4= '\n local name_t= { '
local scr5 = '\n} '
local scr6 = '\n return name_cont, name_t end \n '
----------------------------
if type(f_t ) == 'userdata' then --- Запись строки-скрипта в файл ----
f_t: write (scr1)
for i = 1, #t_str do f_t:write (t_str[i]) end
f_t: write (scr2)
f_t:write (scr3)
for k, v in pairs ( context_t ) do f_t:write ( '\n [ [[' .. k .. ']] ] = [[' .. v ..']],' ) end
f_t:write (scr5)
f_t:write (scr4)
for k, v in pairs ( name_t ) do f_t:write ( '\n [ [[' .. k .. ']] ] = [[' .. v ..']],' ) end
f_t:write (scr5)
f_t:write (scr6)
f_t:close()
return
else ----------------------
local s_a = {} --- для сбора строк ----
----
local s = scr1 .. m_str_to_str_fast ( t_str)
s_a[ #s_a + 1 ] = scr2
s_a[ #s_a + 1 ] = scr3
for k, v in pairs ( context_t ) do s_a[ #s_a + 1 ] = '\n [ [[' .. k .. ']] ] = [[' .. v ..']],' end
s_a[ #s_a + 1 ] = scr5
s_a[ #s_a + 1 ] = scr4
for k, v in pairs ( name_t ) do s_a[ #s_a + 1 ] = '\n [ [[' .. k .. ']] ] = [[' .. v ..']],' end
s_a[ #s_a + 1 ] = scr5
s_a[ #s_a + 1 ] = scr6
s_a = m_str_to_str_fast ( s_a) -- массив строк -> строка
-----
s = s .. s_a
if ph_f == 1 then
return s --- Строка-скрипт ---
else
return load ( s ) -- !!! байт-код скрипта (два результата) ---
end
end
------
end
----------------------------------------------------------------------
--- str_to_tbl (<Байт-код скрипта для восстановления <T>, либо строка-скрипт)>[, <Контекст>] )
--- Результаты. Их может быть один или три (если есть висячие ссылочные значения):
-- 1-й - восстановленная таблица с gjvtnrjq висячих ссылок, если такие существуют в виде составных имен в контексте сереализации.
-- Второй и третий – nil, если висячих ссылок нет или две таблицы:
-- - таблица висячих ссылок с указанием составных имен-адресов в кон-тексте сереализации;
-- - таблица висячих ссылок с указанием составных имен –адресов в <T>.
-- В таблицах висячих ссылок есть данные, облегчающие восстановление этих ссылок.-
------
local function str_to_tbl (str_fun, context)
--MessageDb ( 2, 0, 'Скрипт', ' str_fun str_fun: \n' .. dump_str ( str_fun , ' ', 0))
if type (str_fun) ~= 'string' and type (str_fun) ~= 'function' then
return nil, '! Ошибка во 2-м параметре ф-ции str_to_tb (он должен быть типа string или function )'
end
local err
if type (str_fun) == 'string' then
str_fun , err = load ( str_fun ); if err ~= nil then return nil, err end
end
---------
local cont_t, tbl_t = str_fun ()
creating_link_tables ( context )
--- Проверка существования ссылочных значений таблицы -----
local cont_err, t_err = {}, {}
local N_err = 0
local v_tm
--- Первый этап разрешения ссылок ---
for k, v in pairs ( cont_t ) do
v_tm = aliases_v_cont [ v]
if v_tm then --- есть ссылочное значение ---
cont_t [k] = v_tm
else
N_err = N_err + 1
cont_err [ k] = v
t_err [ k] = tbl_t [k]
end
end
--- Второй этап разрешения ссылок ---
if N_err > 0 then
local cont_err_tm = cont_err
for k, v in pairs ( cont_err_tm) do
local i_mt = # v
local v_tm, yes
for i = i_mt , 1 do if v: sub(i, i) == ',' then i_mt = i; break end end
if i_mt <= # v then
for i = i_mt - 1 , 1 do if v: sub(i, i) == ',' then i_mt = i; break end end
i_mt = i_mt + 1
v_tm = v: sub(i_mt)
yes = nil
for k_k, v_v in pairs ( aliases_v_cont ) do ---
if k_k: find( v_tm, i_mt) then
cont_t [k] = v_v; yes = 1 break
end
end
if yes then
N_err = N_err -1
cont_err [ k] = nil
t_err [ k] = nil
end
end
end
end
-----
if N_err > 0 then
return str_fun (cont_t), cont_err, t_err
else
return str_fun (cont_t)
end
end
-----
return { tbl_to_str = tbl_to_str, str_to_tbl = str_to_tbl, creating_link_tables = creating_link_tables, dump_tbl = dump_tbl , m_str_to_str_fast = m_str_to_str_fast } ---