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

  Пусть это и демонстрирует реальная жизнь

Точно также, если переключение (! оно не может возникать внутри команд Lua-машины, а только между ними) в байт-коде вдруг возникнет после tid = nil, но до DestroyTable, то оно снимает лок, мейн видит вместо таблички нил и все правильно понимает. При этом исполнение кода в мейн не сможет блокировать поток обработки колбеков и DestroyTable тоже успешно выполнится. В чем вы видите проблемы?

 Я помню, что в Qlua есть потокобезопасные функции, обеспечивающие функциональность критической секции и нет проблем использовать их в представленном вами примере (вы с этим сами можете разобраться и я не буду тратить время на то, как это можно сделать), Я только не очень понимаю зачем это может потребоваться в приведенном вами примере?
 Но дело обстоит еще проще. Если вы знакомы с документом разработчика QUIK «Использование Lua в Рабочем месте QUIK.pdf», то его в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков фондового рынка, которую можно распространить и на обработку колбеков событий таблиц QUIK. Если придерживаться этой схемы, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном. И не надо ни чем извращаться ни в одной строчке скрипта так как при этом он становится однопоточным (относительно основного потока обработки колбеков). Вы можете почитать комментарии, начиная с https://forum.quik.ru/messages/forum10/message56387/topic6356/#message56387 , в которых это обсуждается с демонстрацией кодов, рекомендуемых разработчикам QUIK.
  Если же в скрипте не используется схема обработки колбеков, рекомендованная разработчиком QUIK, то преобразование любого такого скрипта в функционально эквивалентный, но с рекомендованной схемой, элементарное.

  Все, что вы написали (включая ссылку) как-то декларативно и нет конкретики. Типа, это не надо делать, потому что не надо.
 Но в вашем комментарии есть фразы, на которые я попытаюсь ответить или задать вопросы.
1.  Каким образом что-то будет ломаться, если будут переключение потоков внутри «чистого» кода Lua (байт-кода)?
---
 Сейчас переключение потоков в QLua возможно, и выполняется при вызове в скрипте C-функций, которых в рабочем скрипте обычно достаточно много (начиная со sleep). И при этом ничего не ломается.
  Что изменится в описанном выше качественно, если будут переключения на участках байт-кода? Ничего!  Вы же можете, без проблем, в существующий скрипт добавить, для своих целей, новые вызовы C-функций внутрь существующего байт-кода и это нормально.
 Предлагаемый мною вариант переключения внутри байт-кода это, по сути, добавление очень эффективного вызова «пустой», ничего не делающей C-функции через определенный интервал выполнения команд байт-кода. Это обеспечивает возможность переключения потоков внутри байт-кода и устранение блокировки потоков длительными фрагментами байт-кода.
  Интервал вызова «пустой» C-функции может быть таким (например, 1000), что дополнительные «окна» переключения потоков  практически никак не влияют на скорость выполнения скрипта (это проверено мною экспериментально). При этом разработчику скрипта. дополнительно к тому, чем занимается его скрипт, ничего делать не надо.

2.  Что это даст всем (скриптерам)?
 Сейчас, если в скрипте выполняется  длительный участок байт-кода main,  то на время его выполнения, блокируется выполнение основного потока, обрабатывающего колбеки всех запущенных скриптов пользователя и обслуживающего события таблиц QUIK. Все аналогично, если описанное выше, происходит в функции, вызванной в колбеке.
 -----
Для демонстрации выигрыша скриптера от реализации обсуждаемого предложения рассмотрим, например, следующую ситуацию.
У пользователя запущено два скрипта (почему бы нет, они будут выполняться в разных потоках):
первый скрипт продуктив, который реально торгует на рынке (обрабатывает колбеки);
второй скрипт продуктив, который тоже реально торгует на рынке (обрабатывает колбеки).
  Если во втором/первом скрипте в какой-то момент времени  будет обрабатываться длинный байт-код в main и при этом в нем вызовется колбек, то поток обработки колбеков всех скриптов будет заблокирован. При этом перестанут обслуживаться и колбеки первого/второго скрипта. Это может произойти неожиданно и в самом неподходящем месте и породить неприятные последствия для торгующего. Этого ожидает пользователь? Надо ли скриптеру, при каждой редакции своих скриптов анализировать свой код на возможность возникновения описанной ситуации или других похожих?
----
 Если бы было реализовано то, что я предлагаю, то описанных выше блокировок не было бы.
 Кто-то скажет, что описанный выше пример надуманный, редкий и так далее. Но, те, кто разрабатывал более-менее серьезные программы, наверное, понимают, что если есть баг в программе, то рано или поздно он может проявиться.
3. И вопрос Антону: все-таки, интересно, какую конкретную функциональность в своих разработках вы реализуете, использую блокировку потоков выполнением длинных участков байт-кода?

 Ну, не я же начал про  форки.  А ответил потому, что подумал, что, вдруг, узнаю что-то новое.

Насчет околесицы не согласен, почитайте наше с вами общение, начиная с комментария: https://forum.quik.ru/messages/forum10/message54757/topic6356/#message54757

  Это уже интересно.
Опишите как такие переключения вам мешают. Мне они никак не мешаю.

То есть, вы вполне удовлетворены тем, что QLua является «форком луа» (если вы отвергаете все остальное, приведенное мною в обоснование того, что QLua, похоже, форк ) хотя бы по причине:
И тогда что это:

1.
  То, что я предложил очень конкретно, работает (прочитайте эту ветку сначала).
Где ваше предложение достичь того же самого без изменения кода Lua?

2. Здесь, как я понимаю, мы с вами обсуждаем конкретное предложение, протестированное  на моем стенде:
  Вместо того, чтобы сделать конкретные замечания по выше предложенному, вы пускаетесь в филосовские рассуждения о том, после какой, внесенной в исходники Lua запятой, считать его «форк луа».  
   Причем, напомню вам, что по вашему же предложению (кстати, поддержанного в комментариях мною) были внесены разработчиком QUIK заметные изменения в обработку исключительных ситуаций Lua.  Наверное, вы ответите, что изменения в обработку исключений не делают Lua «форком луа» .

  Мне кажется, с предупреждением, вы опоздали (как всегда, "все украли до нас" ).
 ARQA уже создала и использует форк луа:
  1) исходники Lua были изменены для обеспечения многопотоковости QLua (смотрите мой комментарий https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696);
  2) сравните размер кода Lua (~300 кб) с размером кода QLua (более 500 кб).

    Относительно обсуждаемой с вами блокировки потоков:
1. Вы для устранения существующей ошибки QLua предложили хороший вариант нейтрализации этой ошибки на уровне разработчика скриптов (все же, требующий нетривиального анализа и, возможно, дополнительного изменения кода скрипта при каждой его редакции).
2. Есть простая возможность (конкретные изменения в код Qlua, вносимые в течении 30 минут) с использованием идеи вашего предложения, устранить обсуждаемую ошибку в QLua таким образом, что от разработчики скриптов вообще освобождаются от борьбы с обсуждаемой ошибкой. Кроме того, семантика выполнения потоков в QLua становится стандартной (выполнение любого потока, само по себе, не блокирует выполнение других).
3. Мне непонятно, если оставаться в рамках профессионального обсуждения возможных решений, почему вы «топите» за то, чтобы ошибка не исправлялась?

 Блокировку потоков длинным участком кода пользователя на "чистом" Lua, наверное, трудно назвать функционалом QLua.

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

     Никакие.  Пользователь анализирует свой код на наличие длинных участков на «чистом» Lua и в «нужных?» местах вставляет вызов какой-нибудь C-функции для переключения_State (с целью исключения блокировки запуска колбенов для других своих скриптов, если они у него есть ( QUIK это позволяет делать)).
---
   Но точно также можно задать похожий вопрос: какие ограничение наложило бы отсутствие в QUIK языка QLua?
   И вот возможный ответ; никакие, все можно написать на  ассемблере.

Вариант решения выше озвученных пожеланий:
1) поток, обслуживающий колбеки событий фондового рынка, занимается только ими (и ни чем другим);
2) добавляется отдельный поток запуска/завершения скриптов и обслуживания таблиц QUIK;
3) для защиты потоков от возможной, взаимной блокировки кодами на «чистом» Lua, реализуется решение (состоящее из конкретных правок в 4-х местах исходного текста QLua), которое было приведено в комментарии https://forum.quik.ru/messages/forum10/message56351/topic6356/#message56351
В чем проблемы реализации такого варианта?
В своей системе реализации многопоточных скриптов OS_Quesha я запускаю столько потоков, сколько мне требуется и они работают нормально.

Так как появился QUIK 9.1, то коды и документация OS_Quesha обновлены и в текущий момент времени работоспособны для версий 7<= QUIK <= 9.1: https://cloud.mail.ru/public/2zn2/2tZgedUu4

Поддержка! В архиве https://arqatech.com/ru/support/files/quik-workstation/
  нет кода QUIK Junior v.9.1

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

  Вы это можете проверить сами экспериментально.

 Согласен.  Правильнее использовать getScriptPath().

 В документе разработчика QUIK: «Использование Lua в Рабочем месте QUIK.pdf», в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков. Если придерживаться ее, то проблем многопоточности (! из-за того, что колбеки запускаются в потоке отличном от потока main) в скрипте пользователя не будет.
 По ссылке https://forum.quik.ru/messages/forum10/message56397/topic6356/#message56397 вы найдете пример из раздела «2. Взаимодействие потоков Lua скрипта».

Функция опреlеления папки запускаемого скрипта:

-------------------
 На самом деле, устранение обсуждаемых здесь ошибочных ситуаций дело разработчика QUIK. Как это реализовать пусть он решает. Что надо устранить вы описали детально и этого, наверное, достаточно.

 Уточнение:
 Для случаев зацикливания или блокировок в завершаемом скрипте пользователя, в основном потоке (а лучше, в специальном служебном потоке, чтобы не отвлекать основной поток от обслуживания колбеков, возможно, других работающих скриптов пользователя) контролировать завершение скрипта. Если за время по умолчанию или явно указанное в OnStop() скрипт не завершен, то выполняется принудительное его завершение, но это, скорее всего, будет происходить редко.

 Присоединяюсь к коллеге.
1. Непонятно, почему таблицы QUIK обслуживаются в основном потоке обработки колбеков. В чем проблема сделать обслуживание таблиц QUIK в отдельном специальном для этого потоке?
2. Зачем завершение скрипта пользователя выполняется в потоке обработки колбеков? Наверное, в OnStop() было бы достаточно выставлять признак завершения скрипта, а все работу по завершению скрипта пользователя выполнять в потоке main.

     Есть все-таки большая разница между «шайбами»:
1) перешел один раз на схему, рекомендуемую разработчиком QUIK, и далее проблемами конфликтов с основным потоком запуска колбеков не заморачиваешся;
2) всякий раз при изменении/добавления кода скрипта анализируй участки кода на предмет его потокобезопасности да еще и вставляй прокладки для защиты от блокировок.

 Любой существующий скрипт, в котором нет очереди  между вызовами колбеков и их обработкой, легко может быть преобразован в вариант скрипта, схема работы с колбеками которого, описана в разделе «2. Взаимодействие потоков Lua скрипта». Поэтому никаких функциональных ограничений данной схемой не накладывается. При этом, так как работа с очередями потокобезопасна, а вся остальная обработка выполняется только в main, то никаких конфликтов скрипта пользователя с основным потоком вызова колбеков не может быть.
-------------------------------------------
  Из раздела «2. Взаимодействие потоков Lua скрипта».

Пример реализации очереди FIFO («первым пришёл — первым ушёл») для обработки
срабатывания функций обратного вызова в функции main():

 Какие ограничения накладывает рекомендуемая разработчиком QUIK схема обработки колбеков на обработку данных в скрипте пользователя?

--
 В документе разработчика QUIK: «Использование Lua в Рабочем месте QUIK.pdf», в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков. Если придерживаться ее, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном.

  Прошло два месяца.
Просьба к поддержки: сообщить результаты рассмотрения пожеланий.
----
 Второе пожелание факультатив и, наверное, его стоит рассматривать после устранения критических ошибок, но первое пожелание (было отмечено сразу при описании пожеланий) это устранение ошибки.
 Напоминаю:
  Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.
 Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов)  являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов.
-----
 Есть простой вариант реализации первого пожелания, кстати, совместимого со вторым  (далее список изменений реализующих этот вариант в в тексте исходни-ков Lua ):
1. В файле   lstate.h  после строки:  lu_byte allowhook;
добавить: int Счетчик_для_переключения_State;
2. В файле   lstate.с  после строки:  L->errfunc = 0;
добавить:  L->Счетчик_для_переключения_State = 0;
3. В файле   lstate.с  после строки:  L1->stacksize = BASIC_STACK_SIZE;
добавить:  L1->Счетчик_для_переключения_State = 0;
4. В файле   lvm.с  после строки:  StkId ra;
добавить:  
if (++L->Счетчик_для_переключения_State > 1000) {   //  1000  надо задать кон-стантой   L->Счетчик_для_переключения_State = 0;
lua_unlock(L); lua_lock(L);
}
------------------------------------  
 В чем проблема реализации первого пожелания?

Я пытаюсь помочь решить наши с вами проблемы потокобезопасности API QLua работы с QUIK.
 Если синхронизация функций API реализована так:
то тех "плавающих" результатов, которые описаны в ветках:
1) Опять ошибка получения кол-ва ордеров скриптом https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе https://forum.quik.ru/forum10/topic6526/ .
по моим представлениям, быть не должно.
 Пусть мне кто-то объяснит, что я ошибаюсь.

   Просьба устранить ошибки, описанные в ветках (там много комментариев и повторять их полностью здесь, наверное не стоит):
1) Опять ошибка получения кол-ва ордеров скриптом https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе https://forum.quik.ru/forum10/topic6526/ .
  Ошибки, описанные в упомянутых выше ветках, скорее всего, ошибки синхронизации функций API QLua. И ошибки такого вида, возможно, имеются и в других функциях API.
  Вообще, все функции API работы с QUIK из QLua должны быть потокобезопас-ными  из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках).
     Написанное в упомянутых выше ветках (с приведением кодов и результатов), демонстрирует, что getDepoEx и getFuturesHolding не являются потокобезопасными.
------
    Возможно, то, что написано далее, разработчики QUIK хорошо понимают, но на всякий случай некоторые соображения.
 Объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем бо-лее не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.

Об областях синхронизации.
  Область синхронизации программы это та часть области видимости переменных программы, для которых предполагается обеспечить атомарность (! всей совокупности этих переменных как единого целого) при многопоточной обработки данных.
  Распространенной ошибкой синхронизации в параллельном программировании является неправильное определение области синхронизации. Для эффективности синхронизации ее область должна быть минимальнонеобходимой (однозначно определяющей результат программы), обеспечивающей корректность работы программы. Если область синхронизации программы содержит в себе минимальнонеобходимую, то все будет работать корректно (но не вполне эффективно). Если же область синхронизации не включает в себя минимальноне-обходимую, то это ошибка программы. Поэтому при разработках, в тех случаях, когда не очевидна минимальнонеобходимая область синхронизации, обычно первоначально область синхронизации выбирается с «запасом». Далее эта область, в процессе развития проекта, может быть «сужена», с целью повышения эффективности синхронизации, до минимальнонеобходимой.

  Да.

 Дополнение (разработчики это, наверное, понимают, но на всякий случай).
 Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций.

А вот и подтверждение этому из разных веток:
1) Опять ошибка получения кол-ва ордеров скриптом: https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе: https://forum.quik.ru/forum10/topic6526/ .
  Ошибки, описанные в упомянутых выше ветках, скорее всего, ошибки синхронизации функций API QLua. И ошибки такого вида, возможно, имеются и в других функциях API.
  Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией.

 Реакции поддержки на просьбу нет.
 Ее трудно выполнить? Или поддержка считает, что выше написанное, не относится к обсуждаемому в данной ветке?

------------
-----------------------------
 Выше приведенные комментарии, скорее всего, означают, что функция getDepoEx не является потокобезопасной. Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  хотя бы из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, ! обращаю особое внимание разработчиков, что объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State.
----
  Просьба к поддержке, довести данный комментарий до разработчиков QUIK.

    Вы меня заинтриговали своей версией QUIK. Пожалуйста, еще раз проверьте версию QUIK, в которой вы работаете. Но если вы подтверждаете эту версию, то укажите брокера, через которого вы работаете. Если вы подтвердите номер версии QUIK, то это, наверное, Центробанк РФ   . Каким образом вы можете работать в QUIK версии на два шага более новой, чем официальная производителя ARQA в текущий момент (на 06.06.21), для меня большая загадка. Но, возможно, мне что-то неизвестно. Кто-нибуть, возможно, поддержка QUIK, может объяснить, как такое бывает?

  Я как пользователь. Хотел вам помочь. Похоже, не получилось.

  Где вы взяли версию 8.13.3.1, если последняя официальная версия на сайте ARQA  8.13.1 (8.13.1.16) от 19.04.21?

 74 сообщения и нигде не указана версия QUIK, в которой запускается программа в которой происходит непонятное. Версию QUIK следует указывать обязательно.
     Если вы работаете с QUIK версии >= 8.5 и < 8.13.1.16, то в них есть ошибка синхронизации, которая может проявляться в виде сбоев (смотрите ветку Отладка QUIK 8.13 ...).

Средства обеспечения устойчивости роботов, создаваемых в OS_Quesha
  Устойчивость (к сбоям аппаратуры, к ошибкам программ и т.д.) торговых роботов является одним из важнейших требований к ним. Программным средством обеспечения ус-тойчивости является контрольная точка. Контрольная точка программы это значения ее переменных (состояние программы), возникшие при ее функционировании и сохраненные в энергонезависимой памяти  для возможности продолжения работы этой программы, начиная с сохраненного состояния, после ее перезапуска по любой причине (сбой аппаратуры, программная ошибка, и т.д.). В идеале, реализация контрольных точек должна быть такой, чтобы работа программы, при включенной контрольной точке, с перезапусками, возникающими в ней по любой причине, функционально не отличалась бы от ее работы без перезапусков. Реально, этот идеал недостижим, и, используя контрольные точки, можно только уменьшить вероятность нарушения функционирования программы при ее перезапусках. Предположим, что только те сбои программы,  моменты, возникновения которых попадают в интервалы времени фиксации ее контрольных точек,  могут нарушать, из-за неопределенности результата такой фиксации, возможность продолжения ее функционирования. Тогда вероятность нарушения функционирования программы с контрольной точкой пропорциональна длительности фиксации ее контрольных точек. Поэтому в OS_Quesha разработаны специальные решения по уменьшению длительности фиксации контрольных точек.
  Для обеспечения контрольных точек многопоточных приложений в  OS_Quesha используются:
1) служебная папка хранения состояния системы stateOS, в которой размещаются файлы для хранения этого состояния;
2) пакет сереализации таблиц Lua;
3) функции работы с состоянием системы.
 Файлы хранения состояния текстовые и могут при необходимости анализироваться в любом редакторе. Содержимое этих файлов это таблицы состояний функций, ведущих свои контрольные точки,  записанные в соответствии с синтаксисом QLua. Рекомендуется состояния функций, работающих в разных потоках, фиксировать в различные файлы состояния. Файлы состояния, имена которых начинаются с символа @, сохраняют инкрементные состояния. Такие состояния могут быть использованы в случаях больших объемов сохраняемых в них данных. Они обеспечивают быструю запись в их файлы, только возникающих в них изменений. Таким образом, в  OS_Quesha обеспечивается независимость длительности фиксации контрольных точек от их размеров.  Фиксация контрольных точек функций потобезопасная и выполняется в отдельном потоке. Например, фиксация таблицы состояния размером в 100 элементов (строки длинной не более 400 символов и числа) выполняется за ~1 млсек.  Для создания файла состояния, удаления, записи в него таблицы состояния, чтения состояния при перезапуске OS_Quesha, используются основные функции:
1) Очистить / реорганизовать файл состояния;
2) Запись (создание)  контрольной точки в файл;
3) Чтение файла контрольной точки.
  Для управления режимом запуска OS_Quesha в ее глобальных настройках существует параметр Restore_OS_QLua. В этом параметре используются два младших разряда. Нулевой разряд: 0 - запуск (без учета истории функционирования); 1 - перезапуск (продолжение работы).  Первый разряд:  0 - не сжимать файлы инкрементных состояния OS при пе-резапуске; 1 – сжимать. Операция сжатия файлов инкрементных состояний обрабатывает, в момент перезапуска OS_Quesha, список команд изменений их состояний и записывает в них, получившиеся итоговые таблицы состояний.
   В шаблоне TS_QUIK.lua демонстрируется использование инкрементной контрольной точки при обработке лимитированных заявок для хранения истории их состояний с учетом событий, возникающих в QUIKе при обработке этих заявок.
   В описании модуля сереализации, представленного ранее в данной ветке, приведена общая схема реализации контрольной точки циклических функции (а-ля main), исполь-зуемых в  OS_Quesha.

  У меня есть, смутное, подозрение, что вы слабо представляете, что мне известно о вариантах представления графов. На самом деле, мне стал не интересен этот диалог. Но я ставлю 99 против 1, что последний комментарий будет ваш    Сдаюсь  

 Способен. Уже ответил. Прочитайте еще раз:
-----
Зачем вы требуете продолжение "банкета"?
Читайте:

 Я это реально делал и не один раз.

 Кто-то сказал, из великих (цитата не точная): «ОГРОМНЫЙ опыт – это тяжелый груз»  

 Я думаю, что вы не правы. Но вы можете считать, что правы   . Ну и ладно. Каждый из нас, наверное, может иметь свое (особое) мнение и это нормально.

 Заявление сильное. Но, конечно, вы так можете думать   .

   С этим не согласен. Можно.
   Пакет сереализации, предложенный мною  в данной ветке ранее, упаковывает в строку (распаковывает) таблицу Lua произвольной структуры (деревья, сети, цикличесие графы и т.д.).

  Собственно, ваши проблемы вам и решать.

 В виде строки можно представить любое дерево
 Где проблемы?

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

 Интересно, что вы делаете с тысячами командами. Вы что, тетрикс реализовали

 Ну, не буду же я здесь описывать пакет IUP. В его описании есть события.

 Многопоточность удобна для меня. И для меня глюки многопоточности давно исчезли на старых версиях QUIK, а сейчас и на новых версиях QUIK.

Структура меню классическая.
Читайте:
И так как диалог работает в отдельном потоке, то никаких "отвисаний от команд, пришедших даже из первого уровня иерархии".

Реализация диалога в OS_Quesha.

    Одной (но не единственной) причиной реализации многопоточности OS_Quesha было: отсутствие в QUIK нормальных средств создания диалога.
  Тот, кто рискнет использовать таблицу QUIK для создания диалога, точно, легких путей не ищет и это подтверждается многочисленными, многогодовыми обсуждениями на разных форумах тех многих проблем, которые при этом возникают.
  Когда мне пришлось перейти на QUIK (в 2019г.), для меня быстро стало понятно, что, то время, которое уйдет на «кувыркание» с таблицами QUIK, лучше потратить на разработку многопоточности, обеспечивающей, наряду с простой реализацией диалога, решение и других задач перевода моего робота на QUIK.
  Возможность порождения в OS_Quesha отдельного потока, обслуживающего диалог, обеспечивает простоту использования существующих бесплатных графических пакетов.  В OS_Quesha был выбран «легкий» (код менее 2Мб) пакет IUP. Этот пакет в текущий момент стабилен и в нем есть версия для работы в Lua. При использовании данного пакета в отдельном потоке, никаких проблем я не обнаружил. Те графические возможности, которые он обеспечивает, для меня, оказались более чем достаточными.
    Форма диалога OS_Quesha запускается в отдельном потоке (никак не связан-ном с основным потоком QUIK, обслуживающим все колбеки и таблицы QUIK), отдельно от окна QUIK и имеет следующий вид:

В ней есть следующие элементы:
1)  меню системы состоящее из двух частей:
-  служебной: Рынок ЦБ, Отладка, Система
-  прикладной (пользовательской): Меню1(образец), Меню2(образец)
2)  поле вывода сообщений диалога;  в это поле выдаются сообщения-ответы на вводимые команды, а также сообщения о критических ситуациях в системе;
3)  поле ввода команд; это поле является командной строкой и используется для ввода сложных команд;    
   строки, не являющиеся служебными командами OS_Quesha, считаются командами приложения и передаются в функцию cmd_OS_Quesha разбора и выполнения команд приложения, описанную в шаблоне TS_QUIK.lua;
4)  поле вывода сообщений системы; в это поле выдаются сообщения о ситуациях, возникающих в системе, не связанных с диалогом.

  Всё вводимое и выводимое полей рабочего места пользователя сохраняется в потокобезопасном журнале диалога OS_Quesha с фиксацией времени возникновения с точностью до 1 миллисекунды.
   Диалог создается на основании его описания (в табличном виде), представленном в шаблоне TS_QUIK.lua, в котором определяются следующие характеристики:
1)  структура меню системы («дерево» меню) и реакции на вызовы его команд;
2)  размеры всех полей диалога;  свойства окон вывода сообщений (очередь/стек и т.д.);
3)  пользовательские меню (примеры Меню1(образец), Меню2(образец)) с заданием пользовательских функций, обрабатывающих команды этих меню (в том числе с заданием любых объектов пакета IUP);
4)  пользовательская функция разбора сообщений поля ввода команд, отлич-ных от служебных.
----
При необходимости, OS_Quesha может быть запущена без формы диалога (это задается в глобальных настройках системы) и тогда все сообщения системы выдаются непосредственно в QUIKе функцией message, но журнал системы при этом ведется как обычно.