Старатель написал: код в сообщении #24 в частности.
Выполненные мною в Lua 5.3 (5.4) тесты атомарности операций вставки/удаления полей в таблицу показали, что эти операции (в условиях реализован-ной многопоточности QLua) все-таки атомарны. Возможно?, есть ситуации, не охваченные тестированием, когда атомарности может не быть. Если же таких ситуаций нет, то мое утверждение, что выложенный Старателем код Queue (с описанием редко возникающей ошибки) создает потокоопасные очереди, ошибочное.
TGB, прекратите фантазировать.
этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных на сайте и написанных под заказ.
s_mike@rambler.ru написал: этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных на сайте и написанных под заказ.
Я же написал, что, похоже, что код потокобезопасный. Но если вам все известно, то объясните, что происходит время от времени в коде Старателя?
s_mike@rambler.ru написал: TGB, прекратите фантазировать.этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных на сайте и написанных под заказ.
Вы что, никогда не сталкивались с ситуацией, когда программы использовались сотнями тысячами пользователями и в этих программах потом обнаруживались ошибки?
s_mike@rambler.ru написал: TGB, прекратите фантазировать.этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных на сайте и написанных под заказ.
Вы что, никогда не сталкивались с ситуацией, когда программы использовались сотнями тысячами пользователями и в этих программах потом обнаруживались ошибки?
Просьба к поддержке довести содержимое этого комментария до разработчиков QUIK. ----- В версиях QUIK (8.13.1.16 и 9.1.3.11), похоже, есть ошибка, демонстрируемая кодом скрипта, который выложен в комментарии далее. Этот скрипт появился в результате анализа редко возникающей «мерцающей» ошибки (похожей на ошибки QLua, описанные Старателем в данной ветке), когда в переменной сразу после присвоения ей значения, это значение на следующем шаге оказывалось искаженным. При одновременном запуске трех экземпляров скриптов в QUIKе, подключенного к учебному серверу, в разные моменты времени, но достаточно часто (~ c 10 минутным ин-тервалом) выдается сообщение о том, что параллельно (одновременно) выполняются байт-код потока колбека и байт-код потока main (смотрите текст скрипта). В существующей реализации QLua такого быть не должно. Можно предположить, что в QLua есть ошибка в реализации запуска колбеков. --- Код скрипта:
Код
--- Функции работы с очередями (написаны на "чистом" Lua без обращения к C-функциям) ---
local new = function ()
return {first = 1 , last = 0 }
end
---
local push = function (self, v)
local last = self.last + 1
self[last] = v
self.last = last
return last
end
---
local pop = function (self)
local first = self.first
if first > self.last then return nil end
local v = self [first]
self.first = first + 1
self[first] = nil
return v, first
end
---
local size = function (self)
return self.last - self.first + 1
end
-----
--------- Создание очереди------
local Queue_QUIK = new()
---------------------------------------
--- Основной поток обработки колбеков "обходит", запушенные на выполнение скрипты, с тем чтобы по событиям запускать их колбеки.
-- При этом должна быть обеспечена корректная синхронизация выполнения байт-кода колбека таким образом, что он не может выполняеться
-- параллельно с байт-кодом потока main.
----------------------
local for_OnParam = 2 -- Множитель количества записей в очередь ----
local N_OnParam = 0
--- OnParam написана на "чистом" Lua без обращения к C-функциям ---
function OnParam(p1, p2)
for i = 1, for_OnParam do
N_OnParam = N_OnParam + 1
-- Зпаись события ---
push (Queue_QUIK, {'OnParam', N_OnParam, {p1, p2}}) -- 1. здесь создаются таблицы и может быть запущена автоматическая сборка мусора,
-- которая работает для всей инсталяции Lua и не является потокобезопасной ---
end
end
---- Обработка событий QUIK (написана на "чистом" Lua без обращения к C-функциям) ----
local function handle_events()
----- #### Для отладки ---
local OnParam_begin = N_OnParam
local size_Queue_QUIK = size(Queue_QUIK)
---------------------------------
--- Чтение очереди событий -----
local ms, first_q = pop (Queue_QUIK)
while ( ms ) do --- Есть события ---
-------------------------------
--- Чтение очереди событий -----
ms, first_q = pop (Queue_QUIK) --Queue_QUIK: pop()
end
---
for i = 1, 1000 do end ---- нагрузка #### Отладка ---
if N_OnParam ~= OnParam_begin then -- Счетчик N_OnParam может иpмениться только в OnParam
-- А это означает, что одновременно (параллельно) работают поток main и основной
-- поток обработки колбеков, что недопустимо.
--- это C-функция, но она вызывается только если N_OnParam ~= OnParam_begin
message ( ' Параллельное выполнение колбека и потока main: N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin)
.. ' size_Queue_QUIK = ' .. tostring(size_Queue_QUIK) )
end
----
end
--------------------------------------------------------------------------------------------------------------------
--------
IsRun = true
function main()
-------------------
while IsRun do
handle_events() ---- функция чтения событий OnParam ---
sleep(2)
end
------------------
end
function OnStop()
IsRun = false
return 10000
end
Я не очень понимаю в чем могут быть проблемы запуска колбеков QLua. Вот вариант как это можно сделать просто ( C-API Lua):
Код
if ( lua_getglobal (<Основной State в котором запускается колбек>, <Имя колбека>) == LUA_TFUNCTION) // запись и проверка переменной колбека скрипта в стек
{
if ( lua_pcall(<Основной State в котором запускается колбек>, <Количество параметров колбека>, <Список параметров колбека>) ~= 0 ) // запуск колбека
{
<Обработка ошибки при запуске колбека>
}
}
else // в переменной колбека не функция
{
<Обработка ошибки пользователя, задавшего в качестве колбека не функцию>
}
Этот вариант обеспечивает возможность (отсутствующую в существующей версии QLua) замены пользователем функции, вызываемой в качестве колбека, при исполнении скрипта.
Поддержка понимает, что пока не будут устранены "кривые, мерцающие, редкие" ошибки QLua, на нее будет постоянно валиться вал разнообразных ошибок из различных функциональностей QLua? Если бы я был разработчиком QLua, то в первую очередь занимался бы устранением именно "кривых" ошибок. Это глобальные ошибки, которые могут проявляться у пользователя в любых местах его скриптов, вводя в заблуждения относительно источника ошибок.
TGB, у меня для вас две новости, как водится: 1) в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом); 2) в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.
Побочное: 1) колбеки так и запускаются, плюс-минус детали. 2) заменить колбек можно, если он был объявлен в виде хотя бы пустой функции. Если не был объявлен, квик его не будет дергать. Очень даже хорошая оптимизация, иначе квик бы на каждое событие разыскивал необъявленные функции во всех скриптах, что несколько затратно, учитывая локи.
Anton написал: в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом);
Все-таки, воспроизводится. ----
Цитата
Anton написал: в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.
Ну. тогда АРКИ надо объявить, что в версия QLua 5.3 не работоспособна. ---
Цитата
Anton написал: колбеки так и запускаются, плюс-минус детали.
Раскажите детали. Мне это было бы интересно.
Цитата
Anton написал: Если не был объявлен, квик его не будет дергать. Очень даже хорошая оптимизация, иначе квик бы на каждое событие разыскивал необъявленные функции во всех скриптах, что несколько затратно, учитывая локи.
Вы, наверное, знаете, что обращение lua_getglobal (<Основной State в котором запускается колбек>, <Имя колбека>) это эквивалентно обращение в тексте скрипта к переменной скрипта (тоесть. выполняется быстро). Это же обращение к полю таблицы. Или вы думаете, что это не так? Тогда подискутируем. А если это так, то о каком "разыскивании по всем скриптам" идет речь, когда происходит обращение к глобальной таблице, определяемой <Основной State в котором запускается колбек>. Вообще то, мне было бы интересно пообщаться с главным разработчиком QUIK. Но вы же, похоже не главный?
Это lua_lock() + lua_getglobal() + lua_unlock(), совершенно бессмысленно это проделывать, точно зная, что в скрипте нет такой функции. Дискутировать лень.
Что то, не сильно, похоже на детали. Например, не охватывается случай "OnParam". А как вы обясните:
Цитата
Anton написал: в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом
----
Цитата
Anton написал: Это lua_lock() + lua_getglobal() + lua_unlock(), совершенно бессмысленно это проделывать, точно зная, что в скрипте нет такой функции. Дискутировать лень.
Ну, конечно, вместо lua_getglobal(...) (кстати, lua_lock() и lua_unlock() выполняется внутри функции lua_getglobal), эквивалентной с точки зрения времени обращения, обращению к глобальной переменной, даже если этой переменной не существует, можно заняться более содержательным алгоритмом регистрации колбеков скриптов (где можно и ошибиться - замечательная возможность).
Никак на данный момент. Вижу, что все случаи показывают большой размер очереди, 200-400 элементов. Это значит, что у коллектора тоже достаточно большая очередь. Это значит, что коллектор начинает агрессивничать и влезать в любую доступную дыру. Где он там дыру в мейне нашел, науке пока неизвестно.
Цитата
TGB написал: кстати, lua_lock() и lua_unlock() выполняется внутри функции lua_getglobal
Я кагбэ в курсе. Специально показал оверхед против просто обращения к таблице из байткода. Спорить мне все равно лень.
Anton написал: Все такое же, имена поменяйте. Там может вообще темплейт в сорце.
Имена я способен поменять, но мы же обсуждаем не то что я могу сделать, а как это сделано в текущем QLua.
Цитата
Anton написал: Это значит, что коллектор начинает агрессивничать и влезать в любую доступную дыру. Где он там дыру в мейне нашел, науке пока неизвестно.
В принципе, если обеспечено четкое разделение между потоками, среды исполнения Lua (то есть, она разделяемый ресурс с корректной синхронизацией доступа к ней) то это эквивалентно однопоточному Lua, в котором ошибки, конечно есть, но их мало.
Anton написал: TGB , у меня для вас две новости, как водится: 1) в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом); 2) в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.
Действительно, в Qlua 5.4 тест ошибку не диагностирует. --- Спасибо Антону за его уточнение. -- А где поддержка?
Просьба (повторная) к поддержке: довести содержимое моего комментария: https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 до разработчиков QUIK. В QUIK 9.2.1.4 (с последними обновлениями) тестовый скрипт, выложенный в упомянутом выше комментарии, демонстрирует, по моему мнению, ошибку в запусках колбеков, в QLua 5.3 ( в QLua 5.4 эта ошибка не диагностируется, но это не означает, что в 5.4 такой ошибки нет).
Где реакция поддержки? ---- Третий раз (первый комментарий был написан 10.09.2021 07:46:28 https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872) обращаю внимание поддержки на то, что тест, выложенный 10.09.2021 07:46:28 в данной ветке, в QUIK (8.13.1.16, 9.1.3.11 и 9.2.1.4 (с последними обновлениями), в QLua 5.3 демонстрирует ошибку в запусках колбеков. Это подтверждено пользователем Anton (смотрите комментарий 61). Если перевести на простой язык, то диагностируется ошибка синхронизации выполнения потока запуска колбеков и потока main скрипта (и это после полутора года эксплуатации новых версий QUIK ). Ошибки синхронизации могут проявляться как случайные сбои в сриптах пользователей в различные моменты времени. Что из выше написанного не понятно? А если непонятно, то где вопросы?
Daniil Pozdnyakov написал: Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.
Здравствуйте! Появилась версия QUIK 9.2.2.11 (с обновлениями). В этой версии в QLua 5.3 тест, описанный в комментарии (10.09.2021) https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 демонстрирует ошибку в запусках колбеков. Эта ошибка может проявляться как случайные сбои в сриптах пользователей в различные моменты времени. В версии в QLua 5.4 ошибка не проявляется У поддержки есть вопросы по тесту?
Daniil Pozdnyakov написал: Проблема, о которой Вы говорите, на данный момент изучается, и, к сожалению, какую-либо резолюцию, а также сроки решения данной задачи дать не можем.
Долго изучаете проблему. Не точно, но скорее всего, колбеки регистрируются в QLua (а этого можно и не делать - смотрите мои комментарии) с помощью функции: void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup) и, наверное, с параметром nup = 0. Параметр nup = 0 означает, что это C - функции и они запускаются без блокировки байт-кодов. Что является ошибкой. ---- Возможно, я ошибаюсь, и все-таки просьба к поддержке: донести этот комментарий до разработчиков QUIK.
TGB написал: Параметр nup = 0 означает, что это C - функции
Этот параметр указывает количество upvalues, прицепленных к каждой функции. Их можно и к сишным функциям прицепить. Соответственно причина явно не в этом. И таки нет, там все просто, lua_pushcfunction + lua_setglobal (возможно, в сорце это один вызов и компилятор его автоматом так разворачивает, тем не менее).
Anton написал: Этот параметр указывает количество upvalues, прицепленных к каждой функции. Их можно и к сишным функциям прицепить. Соответственно причина явно не в этом.
Вообще, мне (и остальным пользователям QUIK) не интересны причины наблюдаемой ошибки. Нам существенно, чтобы эта ошибка была устранена.
TGB написал: Не точно, но скорее всего, колбеки регистрируются в QLua (а этого можно и не делать - смотрите мои комментарии) с помощью функции: void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup) и, наверное, с параметром nup = 0. Параметр nup = 0 означает, что это C - функции и они запускаются без блокировки байт-кодов. Что является ошибкой.---- Возможно, я ошибаюсь, и все-таки просьба к поддержке: донести этот комментарий до разработчиков QUIK.
спасибо за Ваш комментарий, он будет учтён при разборе.
Anton написал: Соответственно причина явно не в этом.
Согласен. luaL_setfuncs не применима к функциям Lua, а только к С-функциям. --- Эксперименты показали, что проблема в lua_pcall (нет блокировки доступа к байт-кодам). Либо в этой функции нет синхронизации в QLua 5.3 (что очень сомнительно), либо в ней не корректно указана ссылка на объект синхронизации (он должен быть общим для всех lua_State скрипта).
TGB, если уж говорить о возможных причинах, я бы посмотрел на хайли лайкли происходящий рехэш таблицы при вставке. Проверить это при наличии сорцев просто, поставить бряк на рехэш и запустить ваш тест. А так "из общих соображений" можно весь луа перерыть.
local for_OnParam = 2 -- Множитель
local N_OnParam = 0
----
function OnParam(p1, p2)
for i = 1, for_OnParam do
N_OnParam = N_OnParam + 1
end
end
---
--------
IsRun = true
function main()
local J
local OnParam_begin
-------------------
while IsRun do
------
do
OnParam_begin = N_OnParam
J = 100000000
while ( J > 0 ) do J = J - 1 end -- ### Проблема здесь. "Чистый" байт-код, но в QLua 5.3 здесь переключаются потоки (! в 5.4 этого нет)----
-- for i = 1, 100000000 do end -- Это в QLua 5.3 работает нормально ---
if N_OnParam ~= OnParam_begin then -- Счетчик N_OnParam может исмениться только в OnParam
message ( ' Переключение колбека и потока main: N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin))
end
end
-----
sleep(10)
end
------------------
end
function OnStop()
IsRun = false
return 10000
end
TGB, нет квика под рукой, посмотрите плиз, вот так воспроизведется?
Код
local for_OnParam = 2
local N_OnParam = 0
IsRun = true
function OnParam(p1, p2)
for i = 1, for_OnParam do
N_OnParam = N_OnParam + 1
end
end
function main()
while IsRun do
do
local OnParam_begin = N_OnParam
local J = 100000000
while ( J > 0 ) do J = J - 1 end
if N_OnParam ~= OnParam_begin then
message ( ' Переключение колбека и потока main: N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin))
end
end
sleep(10)
end
end
function OnStop()
IsRun = false
return 10000
end
Извиняемся за задержку с ответом. К сожалению, нам не удалось понять причину возникшей ошибки. В случае повтора просьба максимально подробно описать обстоятельства возникновения ошибки. Приносим извинения за причиненные неудобства.
TGB написал: Просьба (повторная) к поддержке: довести содержимое моего комментария: https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 до разработчиков QUIK. В QUIK 9.2.1.4 (с последними обновлениями) тестовый скрипт, выложенный в упомянутом выше комментарии, демонстрирует, по моему мнению, ошибку в запусках колбеков, в QLua 5.3 ( в QLua 5.4 эта ошибка не диагностируется, но это не означает, что в 5.4 такой ошибки нет).
Добрый день.
Поведение Lua 5.4 считаем правильным, т.е. именно таким, каким было задумано её автором, и рекомендуем использовать именно её.
Alexey Ivannikov написал: Поведение Lua 5.4 считаем правильным, т.е. именно таким, каким было задумано её автором, и рекомендуем использовать именно её.
Здравствуйте. Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков. Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.
Anton написал: local for_OnParam = 2 -- Множитель local N_OnParam = 0 ---- function OnParam(p1, p2) for i = 1, for_OnParam do N_OnParam = N_OnParam + 1 end end --- -------- IsRun = true function main() local J local OnParam_begin ------------------- while IsRun do ------ do OnParam_begin = N_OnParam J = 100000000 while ( J > 0 ) do J = J - 1 end -- ### Проблема здесь. "Чистый" байт-код, но в QLua 5.3 здесь переключаются потоки (! в 5.4 этого нет)---- -- for i = 1, 100000000 do end -- Это в QLua 5.3 работает нормально ---
if N_OnParam ~= OnParam_begin then -- Счетчик N_OnParam может исмениться только в OnParam message ( ' Переключение колбека и потока main: N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin)) end end ----- sleep(10) end ------------------ end
Вариант возможной ошибки. ---------------------- цикл for i = 1, 100000000 do end - пустой. Оптимизирующий компилятор его просто выкинет. ---------------------- Переменная N_OnParam меняется внутри колбека, т е внутри основного потока. ------------------ эта переменная определяет параметр OnParam_begin для if сообщения в потоке main. ------------------------------ Проверка условия и смена параметра асинхронны. ------------------------------- Т е в зависимости от активности на бирже и загрузке процессора условие может не выполнятся никогда. -------------------------- т е будем получать редкие глюки в зависимости от активности торговли и загрузки процессора. Что собственно и наблюдается. ------------------------- Все верно?
nikolz написал: цикл for i = 1, 100000000 do end - пустой. Оптимизирующий компилятор его просто выкинет.
Разве что внешний какой-нибудь. Квиковский не выкидывает.
Цитата
nikolz написал: условие может не выполнятся никогда
Оно не должно выполниться никогда по логике переключения потоков в луа текущих версий. И в 5.4 не выполняется никогда, а в 5.3 выполняется. Вот об этом и разговор тут, мол поправить бы.
Код-то не мой скопировали. Я его менял, предположив, что поток переключается в момент создания замыкания, и занес локальные внутрь do-end, дабы проверить. Но не угадал. В общем случае в 5.3 замыкание может создаваться небезопасно, а в 5.4 этот кусок изменен, так что вполне вероятно, что ноги все-таки оттуда растут. Ковырять некогда.
Anton написал: В общем случае в 5.3 замыкание может создаваться небезопасно
При корректной синхронизации (в тех местах кода Lua, определенных разработчиком Lua) в той схеме, которую определили разработчики Lua для использования ее во многих потоках, почему? Не понял. В этой схеме работа Lua эквивалентна ее однопоточному использованию. Я это проверял и пока ошибок у разработчиков Lua не обнаружил.
В предыдущем моем комментарии у меня не было времени подробно пояснить, что понимается под схемой использования Lua во многих потоках. Попробую это сделать сейчас. Главный thread и остальные thread Lua пространственно, по стеку, разделены и поэтому могли бы обрабатываться в разных потоках без синхронизации. Но не допустима обработка любого thread в нескольких потоках. Если в разных thread нет общих модифицируемых данных, то синхронизация между thread не требовалась бы. Казалось бы, thread могли бы работать параллельно, синхронизируясь только на общих модифицируемых данных. Однако, в Lua есть «общее хозяйство» всех thread , требующее синхронизацию – это общая автоматическая память Lua, поддерживаемая мусорщиком, «заточенным» разработчиками Lua только на однопоточное использование. Поэтому VM-Lua можно использовать в разных потоках только в разделяемом режиме. В любой момент времени VM-Lua может обрабатывать только один поток.
То есть даже не то что может быть небезопасно, как я по памяти написал, а всегда небезопасно. А в 5.4 это место по-другому сделано.
Для уверенности еще надо доказать, что в этом примере компилятор использовал OP_CLOSURE, а не что-то другое. Для этого надо скомпилировать (именно в квике) в файл и отреверсить результат. Мне некогда заняться.
Anton написал: А в 5.4 это место по-другому сделано.
Поправлюсь: по-другому, но тоже есть yield на главном пути. В общем, надо установить сначала, присутствует ли этот опкод в байткоде циклов в обеих версиях, иначе голое теоретизирование получается. Если окажется, что в 5.3 опкод есть, а в 5.4 нет, то задача решена. Если что-то другое окажется, то, глядя на байткод, можно будет просто ручками пройти по нему и посмотреть, что происходит, а не просто пытаться угадать.
Лок выпустить может только мейн, раз уж он его захватил. Никакие телодвижения со стороны главного потока квика его не выпустят. Отсюда варианта два: 1) главный поток квика где-то лезет в луа без захвата лока; 2) лок выпускается одним из опкодов на картинке. Например, JMP может вызывать luaF_close, а она luaM_free, а она может вызывать luaC_fullgc, если определен макрос HARDMEMTESTS. Поэтому первое, что б я сделал, это посмотрел на предмет наличия этого макроса в 5.3.
Anton написал: Никакие телодвижения со стороны главного потока квика его не выпустят.
А вот тут наврал. Таки можно выпустить из другого потока, проверил сейчас. Тксть на майкрософт надейся, а сам не плошай. Значит, есть третий вариант: 3) основной поток квика зачем-то выпускает лок, который не захватывал.
Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
Alexey Ivannikov написал: Добрый день.Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
Здравствуйте. Действительно, обсуждаемую ошибку в 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.
Alexey Ivannikov написал: Добрый день.Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
Здравствуйте. Действительно, обсуждаемую ошибку в 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.
Здравствуйте!
Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.