TGB (Все сообщения пользователя)

   Эти вопросы, наверное, должна была задать поддержка, но когда она это сделает не-понятно.
 Просьба к Старателю, ответить на следующие вопросы:
1) Как часто это возникает?
2) Где это происходит (в потоке main? В колбеках?)?
  Если это возникает в main, то, как реализован цикл, в котором ошибка проявляется. Это: 1) while; 2) repeat; 3) for  или как-то иначе?  Вопрос «как реализован цикл?» возник, по той причине, что в тесте, представленном мною в этой ветке (https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500) и демонстрирующем ошибку в QLua 5,3, с высокой частотой, при замене while на for, ошибка  не проявляется.
-----
   Вопрос к разработчику QUIK: где гарантия, что существующая ошибка QLua 5,3  отсутствует в QLua 5,4?  
3) Есть ли возможность создать тест, в котором обнаруженная вами ошибка QLua 5.4 проявляется часто?

     Не уверен, но возможно, вас может заинтересовать то, что мною представлено в ветке по ссылки https://forum.quik.ru/forum10/topic6198/. Я сейчас занят и со своей стороны, в текущий момент, я смогу только ответить на какие-то ваши вопросы (если они будут).

  Вы, что, еще не поняли, что фондовый рынок на текущий момент не существует? Это не моя жалоба: я в декабре 2021г. избавился от всех бумаг.
-----
 Наикрутейший алгоритмист и программист я   .  Но какая наивность в это поверит?

Roffild
Мне кажется вы не вполне поняли меня.
Ключевой фразой является:

Интересно, временами, наблюдать битву титанов, когда "титанник", практически, уже почти утонул   .

 Мявкну
----
  Несколько замечаний по выложенному вами скрипту.
1. loadstring в версиях QLua > 5.1  не существует. В этих версиях надо использовать load (это все QUIK версии >= 8.5).
2. Фрагмент:
if x%t[i]==0 then
   loadstring("f"..t[i].."("..i..")")();
end;
работоспособен только  в предположении того, что х непрерывная последовательность секунд.
  Кто гарантирует, что x=os.time() в приведенном коде всегда выдаст x+1 сек.? Даже если реакция на таймерные события message (……), то в операционной системе ПК могут возникнуть работы, требующие > 1 сек. и, тогда в последовательности x возникнут пропуски, потенциально приводящие к пропуску таймерных событий (возможно, важных для торговли).
3. Зачем в цикле используется loadstring (load в версиях QUIK >= 8.5)? Эта функция вызова программы Lua для трансляции строки в байт-код и хоть она выполняется быстро, зачем это делать? Конечно, если скрипт пишется только для себя, то его производительностью надо заниматься в последнюю очередь. Но, если есть понимание, то почему бы не реализовать более эффективный скрипт?
4. Для эффективности выполнения скриптов Lua везде, где это возможно, следует использовать переменные со спецификацией local.  Переменные со спецификацией local хранятся в стеке блоков Lua (обращении к ним – прямой, быстрый доступ). Переменные без спецификации local, это поля таблицы, которая хранится в служебной переменной _ENV (для версий Lua > 5.1) и обращение к ним, это обращение к полям таблицы с использованием ее индексов.  Это же относится и к спецификации создании функций Lua.
-----
С учетом выше приведенных замечаний, выкладываю модифицированный код вашего скрипта:

 Добавлю "пять копеек"
  Непосредственно биржей (например, ММВБ) обрабатываются только биржевые заявки: лимитные, рыночные, айсберги. Все условные заявки пользователей, в том числе изменение заявки, отрабатываются на сервере-QUIK  брокера с использованием биржевых заявок. Причем, чтобы не было необеспеченных биржевых заявок пользователя, это делается с учетом текущего состояния лимитов пользователя. На все это тратится вычислительный ресурс и сетевой трафик.
   Время выполнения заявок пользователя определяется интенсивностью входных потоков заявок пользователей брокера (а также общим объемом уже выставленных заявок), производительностью обработки биржевых заявок на бирже, производительностью железа (физического сервера), на котором выполняется сервер-QUIK  брокера, качеством используемой сети и качеством реализации сервера-QUIK.
   Проблема задержки выполнения заявок это, конечно, к брокеру.

P.S.
 Вообще то, одними из главных критериев качества любой программы, конечно же, являются: соответствие заявленной спецификации, а также ее надежность. Но, когда приходится видеть программы (в том числе и известных международных брендов), которые часто используются сотнями тысяч пользователями (с нетерпением, ожидающих свои результаты) и которые можно ускорить, иногда,  не в пять, а в 500 раз, за счет использования более эффективных алгоритмов (и это реализовывалось  практически), то, возникает ощущение, что с эффективностью многих существующих программ имеются большие проблемы. Что такое 500 раз? Это значит, что программа, выдающая результат спустя 8 минут, может выдать его через 1 секунду (при этом еще и энергия экономится   ).

     Не хотелось мне это писать, но вынудили: «Горбатого исправит только могила».

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

 И, конечно, разработчик QUIK не мог не добавить свои пять копеек .
------
 Вам это понятно?

 1. Из ваших комментариев следует (и я с этим согласен), что в текущем QLua:
     1) перед запуском колбека сборка мусора отключается;
     2) после запуском колбека сборка мусора включается;
     3) в неизвестном месте и в неизвестное время периодически делается уборка мусора.
 2. В своем комментарии 167 и повторно в 190 я предлагаю вообще при обработке колбеков оставить мусорщик в покое. Он в соответствии с параметрами, заданными по умолчанию (а может быть и пользователем) сможет автоматически собирать мусор как-нибудь сам. Зачем весь гемморой, перечисленный в пункте1? И мне интересен ответ разработчика QUIK.
    Я уже как то писал: что чем меньше дергаешься, тем реже падаешь . Кому это непонятно?

 И не тратит на это никаких вычислительных ресурсов?

  Вы обратили внимание на то, как меняется память при запуске вашего теста: до ~ 150 000 кб в конце теста.?

  Вы попробуйте убрать  'step' и увидите как растет память используемая тестом. Пусть разработчик QUIK напишет, что 'step' не используется и как при этом не "распухает" память скрипта.

  Я в своем предыдущем комментарии не рассказываю о том, что сборка мусора занимает какой-то ресурс. В тесте показано (при конкретных параметрах), что «дергание» мусорщика в колбеках может увеличивать расход процессорного времени в 25 раз по сравнении с вариантом когда мусорщик не дергается.

1. Из названия данной ветки, наверное, можно понять, что в ней не обсуждается оптимальное построение торговых роботов на чистом Qlua с учетом «кривизны» реализации Qlua. В ней обсуждается аномальное поведение QLua в некоторых конкретных случаях, приведенных пользователями.
Разработчик QUIK мог бы либо объяснить, либо устранить обсуждаемые ситуации, но этого не делается.
----------------------------------
2. Где содержательный ответ разработчика QUIK на мое предложение: не «дергать» мусорщик в колбеках, представленное в  сообщении 167 данной ветки?
 В последней версии QUIK 9.3.3.3 от 08.02.22, в колбеках, мусорщик продолжает (как это было и в предыдущей версии) отключаться, а затем включаться.
-----
  Для того, чтобы мое предложение было более понятно, приведу код теста, в котором демонстрируется разница между вариантом с «дерганием» мусорщика в колбеках и вариантом, когда этого «дергания» нет.  Параметры теста: 1) n - количество переменных используемых в тесте; 2) for_OnParam – нагрузка в колбеке; 3) N – количество циклов моделирования вызова колбеков.
 Разница затрат процессорного времени в вариантах, полученная в тесте нехилая: для параметров теста: n = 10000, for_OnParam = 10, N =10000 предложенный мной вариант в ~25 раз эффективнее чем с «дерганием» мусорщика.  Причем в варианте с дерганием мусорщика в колбеках, как описывает Старатель, длительность обработки колбеков существенно зависит от количества переменных, используемых в тесте (n).
  Тест выполняется без подключения к серверу, но в нем моделируются два обсуждаемых варианта. Мне не известен код QLua и поэтому, возможно, что-то мною упущено из вида, но если у разработчика QUIK есть вопросы к тесту, то я постараюсь на них ответить и задать свои. Некоторые пояснения представлены в комментариях кода теста.

  Код теста:

-----------------------------------------

    3. Выкладываю памятку для поддержки, используемую на моих проектах. Вдруг, кому то, из читающих данную ветку, она покажется интересной.
  ----
 Памятка короткая и потому привожу ее текст полностью.

                                                        Памятка по работе поддержки с пользователями проекта
1. Пользователи являются ценнейшим ресурсом любого проекта, правильное управление которым существенно определяет успех проекта. Фактически это внештатные бесплатные отладчики проекта. Поэтому к ним следует относиться очень внимательно и доброжелательно. За найденные ими ошибки в проекте или предложения, улучшающие проект, их следует благодарить. К ошибкам, совершаемые ими, относиться спокойно и давать четкие разъяснения таким образом, чтобы не отбивать желания повторного обращения.
2. При работе с пользователями, как правило (через некоторое время),  можно выделить следующие группы пользователей:
  1) суперпользователи;   эта наиболее ценная для проекта группа пользователей, хорошо разбирающаяся в проекте, предлагающая ценные решения и конструктивно взаимодействующая с поддержкой проекта по его отладке;  как правило, это группа небольшая и поддержке проекта следует обращать на ее особое внимание, выделяя для общения с ней своих наиболее квалифицированных сотрудников, а также ключевых разработчиков проекта;
  2) ключевые пользователи; это следующая, по ценности для проекта,  группа пользователей, на работу с которой следует уделять повышенное внимание со стороны поддержки проекта;
  3) пользователи;
  4) тролли и хамы;   эта группа, кроме того, что засоряет каналы коммуникации, наносит имиджевый урон проекту;   поэтому ее следует блокировать.

Дополнительно.
При общении с пользователями, надо исходить из того, что:
1) пользователь имеет право на ошибки;
2) на любую ошибку пользователя, диагностируемую в программе проекта, должна выдаваться понятная ему диагностика;
3) любое «падение (зацикливание, блокировка, неожиданное завершение)» программы проекта, является ошибкой разработчика программы проекта;
4) параметры производительности программ проекта важны для пользователей (а в некоторых проектах очень) и являются критериями оценки успешности проекта, наряду  со стабильностью и всеми остальными критериями оценки проекта.

08.02.22 Выложена версия QUIK 9.3.3. Похоже, взамен того, что было выложено в конце 2021 г.
----
Среди исправленных недоработок:
Медленная работа Рабочего места QUIK в некоторых случаях при запуске или во время работы.
Но это надо, наверное, проверять.

 Anton  :
 «Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг.»
-----
   То, что написано коллегами выше достаточно для того, чтобы устранить обсуждаемую ситуацию. Скорее всего, надо убрать запуски мусорщика (lua_gc) в колбеках. И вообще, не надо разработчику трогать уборку мусора.
  Что из выше написанного непонятно разработчику QUIK? Какие есть возражения по предложенному варианту устранения ситуации?
-----
   Если же, вдруг, непонятно, написанное коллегами, то  я попытаюсь детализировать их сообщения.
  Запуск  уборки мусора в колбеках это такое «ноу-хау», от которого «оторопь берет» . lua_gc одна из самых сложных и тяжелых функций Lua. Особый цинизм состоит в том, что сборка мусора запускается в колбеках. Пусть поддержка/разработчики QUIK объяснят, зачем это делается?? Что при этом решается?
  Разработчик QUIK понимает, хотя бы приблизительно, как работает сборка мусора в Lua?
Приблизительно работу мусорщика можно описать тремя пунктами.
1. При запуске функции lua_gc, работает только эта функция.
2. Время работы lua_gc зависит от параметров ее запуска и, как минимум, пропорционально количеству переменных, используемых в скрипте:
  1) собираются все используемые в текущий моменты области памяти скрипта (и для этого во многих случаях надо сканировать все объекты/переменные скрипта);
  2) те области памяти, которые не попали в список, собранный в пункте 1), возвращаются системе.
3. Если не «химичить» с принудительными запусками мусорщика, он будет запускаться автоматически в какие то моменты, определяемые состоянием памяти скрипта и его настройками. И это будет происходить, конечно же, не с высокой частотой возникновения колбеков.
 Если же моя попытка объяснения деталей проблемы не достигла цели, то вот цитата из книги «Программирование на языке Lua» Р. Иерузалимски:
   «В другом крайнем случае сборщик может производить полный цикл сборки мусора при каждом изменении графа доступности. Такая программа будет использовать самый
минимум необходимой ей памяти ценой гигантского потребления процессорного време-ни»
----
  Зачем разработчику QUIK «гемморой» с принудительным, бессмысленным частым запуском уборки мусора, да еще в единственном общем потоке обработки колбеков QUIK?
  Пусть с этим разбираются скриптеры (если знают как).

   Я повторю (так так текст достаточно короткий) то, что мною было написано 10.06.2021 12:57:14.
             Об областях синхронизации.
 Область синхронизации программы это та часть области видимости переменных программы, для которых предполагается обеспечить атомарность (! всей совокупности этих переменных как единого целого) при многопоточной обработки данных.
 Распространенной ошибкой синхронизации в параллельном программировании является непра-вильное определение области синхронизации. Для эффективности синхронизации ее область должна быть минимальнонеобходимой (однозначно определяющей результат программы), обеспечивающей корректность работы программы. Если область синхронизации программы содержит в себе минимальнонеобходимую, то все будет работать корректно (но, возможно, не вполне эффективно). Если же область синхронизации не включает в себя минимальноне-обходимую, то это ошибка программы. Поэтому при разработках, в тех случаях, когда не очевидна минимальнонеобходимая область синхронизации, обычно первоначально область синхронизации выбирается с «запасом». Далее эта область, в процессе развития проекта, может быть «сужена», с целью повышения эффективности синхронизации, до минимальнонеобходимой.
-----
И  10.06.2021 13:59:1.
 Возможно, то, что написано далее, разработчики QUIK хорошо понимают, но на всякий случай некоторые соображения.
   В рабочем месте QUIK объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов QUIK массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.
---------
   На самом деле, достаточно показать, разницу по времени выполнения в разных версиях QUIK и, как я понимаю, пользователями в этой ветке сделано.  Для разработчиков QUIK этого должно быть достаточно.

      Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена. Но, возможно? ,  в QUIK 9.3.3.3 была изменена схема синхронизации в функциях API  QLua (на форуме можно найти много нареканий на ошибки работы некоторых из них, связанных, скорее всего, именно с ошибками синхронизации).
    Существует проблема использования нескольких скриптов в одном рабочем месте QUIK. Это связано с тем, что поток, обслуживающий все колбеки (фондового рынка и таблиц QUIK) один (блокировка в котором блокирует все скрипты рабочего места) и, если в колбеках, есть обращение к функциям API QLua, то все запущенные скрипты рабочего места QUIK, могут выстраиваться в очередь к синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно синхронизации вообще не было), что эквивалентно их работе в одном потоке. Если выше написанное имеет место, то решением может быть следующее: между потоком обслуживания колбеков и потоками main в скриптах создаются очереди, в которые записываются только параметры, обрабатываемые в main. Это делается просто, но можно использовать и готовый модуль, код которого приведен по ссылке: https://quikluacsharp.ru/stati-uchastnikov/modul-realizatsii-interfejsa-obrabotki-sobytij-quik-s-ispolzovaniem-ocheredej-sobytij/

 Ну тогда "хлебайте" то, что вам предлагают и не жалуйтесь на новые версии QUIK (вы же в них не работаете).

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

   Я думал что вы бесстрашный  
   Вы же можете оставаться на "любимых" вами версиях (даже на QUIK 7....) достаточно долго (минимум, лет 5). Какие у вас проблемы?

  А что же вы боретесь с новыми версиями?  

  А почему бы вам не вернуться на исконно-посконную версию QUiK 8.5, которая, как я понимаю, с вашей точки зрения, более стабильная?

  У вас такой печальный опыт. У меня была счастливая возможность наблюдать, а иногда и участвовать в том, как качество программ программ, со временем, улучшалось.
  Надеюсь что и вам, если вы будете переходить на новые версии QUIK, выпадет (через год?) такое счастье   . А чтобы ощутить это сейчас, вы могли бы перейти на QUiK 8.5, а потом вернуться на версию, которую используете сейчас.

  Декларация вашего мнения в данной ситуации не очень существенна. Оно уже многократно вами озвучено и старо как этот мир: не пущать    Но жизнь не остановить. Будут новые версии QUIK. Будут в нем ошибки и исправления. Странно то, что вы с этим продолжаете безнадежно бороться. Вы что, жизни не видели?

 Без учета эффекта Доппера и спина электрона  ваше объяснение не канает  

 Это вы под ником nikolz комментарии пишите?  

   Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипта ?:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
    -----

Вам не лень всякий раз цитировать комментарии пользователей полностью?
Не можете удержаться перед халявой?
Вы же так можете разорить АРКУ на накопителях базы форума  

1.  Я бы на месте АРКИ зачислил вас в нештатные сотрудники  
---
2. Конечно, при разработке скриптов желательно чтобы они были (выполняя свои функции) как можно проще и допускали простоту последующей модификации.
    Рыночная эффективность торговой стратегии (ее доходность на определенном перио-де) может не сильно коррелировать с ее сложностью. Поэтому при разработке скрипта имеет смысл начинать с простых стратегий, не требующих много данных и вычислений и только потом добавлять учет дополнительных факторов поведения рынка.
    QUIK не то место, в котором надо заниматься событийным программированием, существенно усложняющим скрипты. Колбеки следует использовать по минимуму. Лучше от-слеживать доступные в QLua состояния рынка, а также состояния выполнения заявок. Заявки лучше использовать только лимитированные, иначе будут возникать рыночные по неконтролируемым ценам. Все сложные заявки системы: со стопами, тейки, айзберги и т.д., если вдруг они требуются, лучше реализовать в самом скрипте с использованием комбинаций лимитированных заявок. Собственные сложные заявки, будут выполняться с некоторой задержкой по времени (по сравнению с системными), во многом определяемой качеством канала связи с вашим брокером, но за это вы будете иметь более полный контроль над ними.  
----
3.  Во втором пункте я написал, что скрипты желательно создавать простыми, Но это вовсе не означает, что инструмент для их создания должен быть «корявым». И когда после очередного изменения QUIK, создание таблиц в OLua начинает выполняться в 16 раз дольше, чем до изменения, то это оскорбляет «мои эстетические чуства»   . Вы понимаете, что в QLua фактически единственный тип это таблица с индексами/ключами и полями (известных типов)?  Замедление в 16 раз это аномальное поведение QLua, с которым должны были разобраться разработчики QUIK. Что они и сделали, выпустив версию QUIK 9.3.3.3, в которой этого замедления нет. Это не значит, что в этой версии нет проблем, о которых написали другие пользователи (это надо проверять). То, что в QUIK возникают и исправляются ошибки это нормально. Главное это чтобы исправленных было больше чем возникших. Плохо то, что поддержка не дает четкого объяснения возникающих ситуаций.
----
  Для того чтобы не разбираться с новыми глюками новых версий QUIK, у вас есть воз-можность выбрать существующую версию с «любимыми» вами глюками  и оставаться на ней столько, сколько вам захочется.

 Предложение почти гениальное, особенно с учетом того, что обуждается проблема производительности скриптов в QUIK  
 У вас нет понимания, что при встраивании Lua в QUIK его разработчиком вносятся изменения, которые способны изменить встроенного Lua?

  Переведите все в терасекунды и вам все станет понятнее  

  Спасибо. А то я этого не знал  

   Вы какую версию QUIK используете?
  Задавая вопрсы надо обязательно указывать версию.

  Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:

  Тест комментария 55 в QUIK 9.3.3.3 (QLua 5.4) выполняется столько же как и в QUIK 8.13.1.16 (QLua 5.4)

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

  А того, что некоторые пользователи достаточно активно используют таблицы Lua (это относится и ко мне) и все, что связано с созданием таблиц, в QUIK 9.3.1.11 (QLua 5.4) выполняется в 16,25 раз дольше чем в QUIK 8.13.1.16 (QLua 5.4).  Это влезли в ваш ПК и снизили его производительность в 16 раз.
   Я не понял, что вы так заботитесь о том, чтобы разработчик QUIK не устранял глюки?
   Если у вас все хорошо, зачем вы мешаете другим пользователям решать свои (а может быть и ваши) проблемы?

  Я бы папуасам не рискнул объяснять, что такое тензорное исчисление, но у меня есть надежда, что поддержка не папуасы
----
 Вообще то, новые версии QLua у разработчика QUIK должны проходить хотя бы простейшие тесты.
  Например, без подключения к серверу:
1) проверка подключения пакетов;
2) проверка скорости выполнения циклических операций;
3) проверка работа таблиц:
-  скорости создания таблиц;
-  скорости доступа к элементов
И так далее ……
----
 Неужели этого у разработчика QUIK до сих пор нет таких тестов?

Имеется ввиду строка:        for i = 1, N do hour = {} end

В ниже приведенном коде выделена строка символами ###, которая в QUIK 9.3.1.11 (QLua 5.4) выполняется в 16,25 раз дольше чем в QUIK 8.13.1.16 (QLua 5.4)
 Где поддержка??

Присоеденяюсь.
-----
 Деградация эффективности QLua показатель низкого качества реализации разработчиками QUIK встраивания Lua в QUIK. Эффективность выполнения скриптов QLua без обращения к API QUIK должна отличаться от Lua только затратами на операции lock/unlock в вызовах функций C-API QLua, а также в VM-QLua (ulock/lock) при вызове C-функций. Причем упомянутые операции в подавляющих случаях «холостые» (потоки не переключают). Все места вызова lock/unlock (ulock/lock) определены в кодах Lua разработчиком Lua.  Разработчику QUIK достаточно корректно реализовать lock/unlock, например, используя критические секции, обеспечивающие эффективную синхронизацию.
   Вопрос к поддержке: какое «ноу-хау» обеспечивает деградацию эффективности QLua новых версий?
-----
 Интересное открытие (пишу без иронии).
 Вопрос к поддержке: a это зачем сделали?  Хотелось бы чтобы разработчик QUIK пояснил как додумался до этого. Какие проблемы это решает?

    Итак, в Qlua 5.4 есть «плавающая» ошибка (скорее всего ошибка синхронизации).
  ---  
  «Простой» тест, диагностирующий некорректную обработку колбеков в QLua 5.3, появился у меня в результате анализа «мерцающей» ошибки в скрипте, похожей на ошибки в QLua 5.4, описанные Старателем, когда в переменной сразу после присвоения ей значения, это значение на следующем шаге оказывалось искаженным. Нельзя исключать, что природа ошибок, обнаруженных Старателем и мною одна и та же.
  Притом, что обсуждаемый тест ошибку в QLua 5.4 не показывает на коротком интервале времени, это совсем не значит, что такой ошибки в QLua 5.4 нет. Дело в том, что проявление ошибок синхронизации по времени может сильно зависеть и от того какая версия QLua используется. Я могу ошибаться, но, скорее всего, схемы синхронизации потоков в QLua 5.3 и в QLua 5.4 аналогичны. Поэтому, если бы разработчик QUIK, нашел бы ошибку в QLua 5.3, то он бы, наверное, нашел бы ее и в QLua 5.4. Обсуждаемый тест воспроизводит ошибку (в описанных мною условиях) в QLua 5.3 в интервале 2-3 мин. с локализацией места с точностью одной строки кода.

Пакеты для Lua 5.4:  https://cloud.mail.ru/public/YCHN/jFfkrPLBq
iup,  lfs, sqlite3
Lua - файлы для сборки пакетов под Lua 5.4.

Появилась очередная версия QUIK 9.3.1.11. В этой версии проблема существует.

  Здравствуйте.
Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
 Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.  Этот тест разработчик может использовать при поиске ошибки в QLua. Просьба передать его коды и описание ошибки в комментарии https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 разработчику QUIK.

 И пусть разбираются разработчики QUIK.

Согласен.

  Я так и не понял, зачем вы анализировали замыкание функций в пустом цикле:

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

   В предыдущем моем комментарии у меня не было времени подробно пояснить, что понимается под схемой использования Lua во многих потоках. Попробую это сделать сейчас.
   Главный thread  и остальные thread Lua пространственно, по стеку, разделены и поэтому могли бы обрабатываться в разных потоках без синхронизации. Но не допустима обработка любого thread в нескольких потоках. Если в разных thread нет общих модифицируемых данных, то синхронизация между thread не требовалась бы. Казалось бы, thread могли бы работать параллельно, синхронизируясь только на общих модифицируемых данных. Однако, в Lua есть «общее хозяйство» всех thread , требующее синхронизацию – это общая автоматическая память Lua, поддерживаемая мусорщиком, «заточенным» разработчиками Lua только на однопоточное использование. Поэтому VM-Lua можно использовать в разных потоках только в разделяемом режиме. В любой момент времени VM-Lua может обрабатывать только один поток.

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

  Здравствуйте.
 Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
  Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.