Похоже, им все понятно. И это главное. Они разработчики QUIK. От них я вопросов не получаю (даже после моих неоднократных назойливых сообщений: а нет ли ко мне каких-либо вопросов?). С ними я готов обсуждать любые проблемы и они знают адрес моей почты.
В упомянутой выше ветке мною был написан прогноз-предложение возможных изменений. Так как он относится и к тому, что обсуждалось в данной ветке, то приведу его текст здесь с небольшим добавлением.
-------------
Я не знаю точно, какие изменения будут, но попытаюсь дать прогноз (интересно, насколько промахнусь). А если промахнулся, то это мои предложения.
Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:
1) вместо регистрации функций обратного вызова, регистрация соответствующих очередей событий (возможно, с теми же именами); я бы сделал эти очереди циклическими, с указанием их длины при регистрации, но не более некоторого значения;
2) вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);
3) добавление функции чтения очередей событий (их параметров).
Эта схема реализует рекомендованную ARQU обработку параметров событий в main. Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.
При этом проблема сбоев автоматической памяти QLua 5.3, о которой я писал не раз в ветке «» должна исчезнуть.
----
Добавление.
Если будет реализована описанная выше схема обработки коллбеков, то, так как реализация QLua станет однопотоковой, мой многопотоковый тест памяти QLua для этого случая не применим.
Пользователь
Сообщений: Регистрация: 12.05.2020
18.12.2020 09:45:29
Появился QUIK 8.11.0.66:
1. С прогнозом возможных изменений в QUIKе я промахнулся и мои предложения по изменению архитектуры QUIK для повышения его устойчивости проигнорированы. За то добавился вариант QLua 5.4.1. Мне хочется это прокомментировать, но слов не нахожу. 2. Для QLua 5.3.5, на текущий момент, все написанное мною в этой ветке остается актуальным. QLua 5.4.1 не проверял, пусть «отлежится». Мои комментарии для поддержки и разработчиков QUIK: 1) 2)
Пользователь
Сообщений: Регистрация: 12.05.2020
23.12.2020 13:49:39
В QUIK 8.11 (QLua 5.3.5) обработка колбеков выглядит следующим образом. 1. QLua 5.3.5 однопоточный и тем самым снимаются вопросы по моему тесту управления памятью в многопоточном QLua. 2. В скрипте пользователя могут существовать два потока одновременно: поток main и основной поток, в котором запускаются колбеки скрипта. Причем выполнение любого из перечисленных потоков блокирует выполнение другого. Таким образом предполагается обеспечивать корректность работы двух потоков в однопоточном QLua 5.3.5. Переключение потоков реализовано следующим образом. Колбеки могут запускаться только тогда, когда поток main «висит» в операции sleep(<интервал ожидания>). Пока запущенный колбек выполняется, поток main не может продолжить свою работу, даже если истек его <интервал ожидания>. Если, вдруг, в колбеке используется операция sleep(<интервал ожидания>), то она выполняется точно также, как это описано для потока main. То есть, зависание колбека на операции sleep допускает выполнение потока main, но при этом поток колбека «отвиснет» только тогда, когда поток main попадет на свою операцию sleep. Реализованную схему обработки событий элегантной назвать трудно, но она позволяет сохранить существующий пользовательский интерфейс.
Пользователь
Сообщений: Регистрация: 21.08.2015
23.12.2020 14:57:33
TGB, неправда. Если бы было правдой, в следующем скрипте между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' вклиниться не могло бы (слипа в мейне нет, следовательно, колбеки не должны выполняться, согласно вашей модели). А они вклиниваются.
Код
local run = true
local nshow = 0
function OnAllTrade()
if nshow < 100 then
message('OnAllTrade')
nshow = nshow + 1
end
end
function dummy(i)
local a = math.sqrt(1.0)
end
function main()
message('Before loop')
for i = 0, 10000000 do
dummy(i)
end
message('After loop')
end
Пользователь
Сообщений: Регистрация: 12.05.2020
23.12.2020 15:22:43
Цитата
Anton написал: TGB , неправда. Если бы было правдой, в следующем скрипте между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' вклиниться не могло
Правда. При выполнении таких тестов (анализ выполнения потоков) необходимо для вывода сообщений вместо message использовать PrintDbgStr. Сделайте такую замену и прогоните ваш тест заново. Для просмотра результатов используйте Dbgview. Я прогонял ваш тест (с предложенной вам заменой). Между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' не вклинилось.
Пользователь
Сообщений: Регистрация: 21.08.2015
23.12.2020 15:32:58
Цитата
TGB написал: Между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' не вклинилось.
Значит увеличьте длину цикла или усложните вычисления в dummy, цикл просто быстро закончился. Вы обнаружили, что на время вызова любой сишной функции (а не только sleep) луа снимает лок, и сделали неправильный вывод, подумав только на sleep. В качестве такой функции может выступить и message, как в примере, и любая встроенная в луа библиотечная функция, и любая функция qlua. И так всегда было, это не новость в последней версии.
Пользователь
Сообщений: Регистрация: 21.08.2015
23.12.2020 15:49:41
Теперь очевидно?
Код
local run = true
local nshow = 0
function OnAllTrade()
if nshow < 10 then
PrintDbgStr('OnAllTrade')
nshow = nshow + 1
end
end
function dummy(i)
local a = math.sqrt(math.sqrt(1.0 * i) * math.sqrt(2.0 * i))
end
function main()
PrintDbgStr('Before loop')
for i = 0, 10000000 do
dummy(i)
end
PrintDbgStr('After loop')
end
Anton написал: Вы обнаружили, что на время вызова любой сишной функции (а не только sleep) луа снимает лок, и сделали неправильный вывод, подумав только на sleep. В качестве такой функции может выступить и message, как в примере, и любая встроенная в луа библиотечная функция, и любая функция qlua.
Обкладывать синхронизацией все используемые сишные функции в однопоточном QLua для меня неожиданное решение. Мне, казалось, что с учетом рекомендуемого ARQA способа взаимодействия колбеков c потоком main через очереди, в существующей реализации достаточно было синхронизировать только sleep. Вообще, в однопоточном QLua можно было бы практически полностью отказаться от всякой синхронизации и от модификации исходного Lua. При этом можно бы было сохранить и существующий пользовательский интерфейс обработки колбеков. Для этого можно модифицировать функцию sleep следующим образом. В модифицированной функции (например, с именем sleep_q) ожидается либо истечение интервала времени (как в sleep), либо появление данных в очередях событий скрипта. При наличии или появлении таких событий в этой функции запускаются все, соответствующие событиям, колбеки скрипта и далее работа продолжается как обычно. В этом варианте: 1) внутри Qlua полностью отсутствует синхронизация, а вся синхронизация, связанная с обработкой очередей между основным потоком и потоком main, может быть сосредоточена в sleep_q; 2) заметно разгружается основной поток (он подготавливает очереди событий (это делает и сейчас) и при необходимости выдает лишь сигнал о начале их обработки); 3) для включения Lua в QUIK не требуется модификация исходного Lua, а значит, облегчается подключение новых версий Lua а также повышается надежность среды исполнения скриптов: 4) в целом, обеспечивается простота сопровождения QUIK.
Пользователь
Сообщений: Регистрация: 21.08.2015
24.12.2020 08:06:46
Цитата
TGB написал: Обкладывать синхронизацией все используемые сишные функции в однопоточном QLua для меня неожиданное решение.
А их никто и не обкладывал. Это не аркино решение, сам луа так устроен. Все очень просто, байткод всегда выполняется под локом, а когда надо вызвать сишную функцию, лок снимается и после возврата захватывается снова. Арке надо было только реализовать lua_lock/lua_unlock, все остальное уже готово. Тут хочу добавить, что если вы в своей длл определяете сишный колбек, то он тоже без лока выполняется (в отличие от луа-колбека). И это отличное место, где можно прострелить себе ногу.
Цитата
TGB написал: Вообще, в однопоточном QLua можно было бы практически полностью отказаться от всякой синхронизации и от модификации исходного Lua.
Исходный луа практически не модифицирован, добавлены только колбеки, предусмотренные в луа для взаимодействия с хостом. Сама qlua.dll ничего не хачит, использует луа как положено через стандартный апи, что местами не очень эффективно, но идеологически правильно.
Насчет однопоточности - так можно было сделать с самого начала, теперь что-то переделывать, похоже, поздновато. И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое. Сравните с виндовыми очередями сообщений, где позиция мыши и нажатые клавиши сохраняются для каждого сообщения, какими они были на момент генерации сообщения, это вот пример, какие сложности возникают. И арке пришлось бы тоже подобным заниматься, закончилось бы полным дампом состояния, прицепленным к каждому сообщению. А как есть - вам дали колбек, квик вас ждет в колбеке, вы забираете то, что нужно именно вам и отправляете в мейн. Тоже не все гладко, кое-что все равно асинхронно даже в колбеке, но это мизер по сравнению с адом, который был бы с наглухо зашитыми в qlua очередями.
Пользователь
Сообщений: Регистрация: 12.05.2020
24.12.2020 13:17:08
Цитата
Anton написал: И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое.
Это не является особенностью предлагаемого решения. Это относится и к существующей реализации. Вообще, это неустранимый фактор в системах реального времени, к которым относится и QUIK.
Пользователь
Сообщений: Регистрация: 12.05.2020
28.12.2020 19:49:31
Цитата
Anton написал: И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое
Дополнительно, насчет минуса?: 5) так как, по появлению нового события, в предложенном решении выдается сигнал, по которому (если есть ожидание потока main на операции sleep_q) запускаются колбеки скрипта, то мы имеем более оперативную реакция пользовательского потока main по сравнению с существующим решением, и описанный вами фактор, в предложенном решении менее значим; 6) в этом решении на пользовательские колбеки нет никаких ограничений (связанных с нагрузкой основного потока обслуживания скриптов), кроме понимания, того, что выполнение колбеков делается в пользовательском потоке; 7) и еще раз: любая синхронизация (для того, кто понимает) - это геморрой, порождающий трудно исправляемые ошибки (совершенно неожиданные), от которого, если есть возможность, следует избавляться.
Пользователь
Сообщений: Регистрация: 12.05.2020
20.01.2021 11:45:08
Мой модифицированный тест управления автоматической памятью QLua в версии QUIK 8.11 Lua 5.3.5, на текущий момент времени, проблем не обнаруживает. --- 1. Есть вопрос к поддержке QUIK: из Lua53.dll, кроме стандартных функций C-API Lua, экспортирует около 100 дополнительных функций. Зачем это делается? Что не могут сделать разработчики QUIK, оставаясь в рамках стандартных функций C-API Lua? ----- 2. Есть предложение: выкладывать библиотеки импорта (.lib) функций Lua53.dll (Lua54.dll и т.д.), например, в папке хранения файла info.exe. Понятно, что такие библиотеки можно создать на основе файлов dll, но, наверное, не все пользователи знают, как это сделать. Эти библиотеки нужны при перетрансляции C-пакетов QLua при переходе на новые версии Lua.
Пользователь
Сообщений: Регистрация: 26.01.2021
26.01.2021 23:15:48
Цитата
TGB написал: Мой модифицированный тест управления автоматической памятью QLua в версии QUIK 8.11 Lua 5.3.5, на текущий момент времени, проблем не обнаруживает. --- 1. Есть вопрос к поддержке QUIK: из Lua53.dll, кроме стандартных функций C-API Lua, экспортирует около 100 дополнительных функций. Зачем это делается? Что не могут сделать разработчики QUIK, оставаясь в рамках стандартных функций C-API Lua? ----- 2. Есть предложение: выкладывать библиотеки импорта (.lib) функций Lua53.dll (Lua54.dll и т.д.), например, в папке хранения файла info.exe. Понятно, что такие библиотеки можно создать на основе файлов dll, но, наверное, не все пользователи знают, как это сделать. Эти библиотеки нужны при перетрансляции C-пакетов QLua при переходе на новые версии Lua.
а разве это не стандартные библиотеки с lua.org? Почему оттуда не скачать?
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
27.01.2021 08:33:01
Цитата
TGB написал: выкладывать библиотеки импорта (.lib) функций Lua53.dll (Lua54.dll и т.д.), например, в папке хранения файла info.exe. Понятно, что такие библиотеки можно создать на основе файлов dll, но, наверное, не все пользователи знают, как это сделать. Эти библиотеки нужны при перетрансляции C-пакетов QLua при переходе на новые версии Lua
Я вот не помню как делать библиотеки импорта на память, но каждый раз просто-напросто загугливаю за 1 минуту пошаговый мануал, коих сотни; вот и всё. Кто с помощью гугла не может сделать lib-файл из DLL - он, уж извините, и пакеты не перетранслирует. Даже при наличии lib-файла
Пользователь
Сообщений: Регистрация: 30.05.2020
09.02.2021 14:45:05
Цитата
Anton написал: байткод всегда выполняется под локом, а когда надо вызвать сишную функцию, лок снимается и после возврата захватывается снова. Арке надо было только реализовать lua_lock/lua_unlock, все остальное уже готово.
Т.е., весь луа-код, в т.ч. и сишные функции из qlua, не может выполняться одновременно в двух потоках? Ну и зачем тогда нужно было городить весь этот огород с двумя потоками, если они всё равно не работают параллельно?
Вопрос к разработчикам: какие преимущества дала такая двухпоточная модель работы Lua-скриптов?
Нет. Сишные функции - любые, из самого луа, из qlua, из пользовательской длл - выполняются без лока. Под локом только байткод. Конкретно в qlua все функции сишные, в самом луа библиотечные функции тоже все сишные.
Забегу-таки вперед паровоза. Без второго потока пользовательский мейн вообще нельзя было бы выполнить от слова никак. Были бы только колбеки, как в индикаторах.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
10.02.2021 13:27:48
Цитата
Anton написал: Забегу-таки вперед паровоза. Без второго потока пользовательский мейн вообще нельзя было бы выполнить от слова никак. Были бы только колбеки, как в индикаторах.
На мой взгляд, задумка оказалась неудачной. У разработчиков, очевидно, была необходимость сделать замену QPILE с его раз в секунду выполнением, причем в отдельном потоке. Для чего и была сделана main(). Но дальше началась мутная каша.
На мой взгляд, надо было сделать две категории скриптов Lua (помимо индикаторов): 1) Чисто событийный скрипт. С нем могут быть только обработчики событий. Срабатывает что-либо в нём только по событиям, в одном потоке (не обязательно основном, но в одном). Для особо скучающих добавить еще периодическое настраиваемое событие таймера, что просто. 2) Скрипт, выполняющий бесконечный цикл исключительно в отдельном потоке. Но опять же только в одном потоке, пусть и отдельном. Это будет просто полноценная замена QPile и радость любителям постоянно что-то колбась без остановки.
А вот замешивание в одну кашу двухпоточности в рамках одного скрипта лишь добавляет слишком сложных глюков, при этом постоянно получая кашу в анных, да еще и залезая в дедлоки порой. Никакой пользы при этом это не приносит совершенно, считаю.
Пользователь
Сообщений: Регистрация: 30.05.2020
10.02.2021 13:46:10
Цитата
Anton написал: Сишные функции - любые, из самого луа, из qlua выполняются без лока
Как можно в этом убедиться?
При вызове, скажем сишной функции из самого lua, сначала ставится lua_lock потом выполняется функция, затем lua_unlock или в обратном порядке: lua_unlock - выполнение функции - lua_lock?
1. Обратите внимание, что первое действие в - захват лока. Любое выполнение луа из квика начинается через lua_pcallk. 2. Обратите внимание на , в частности на строки (также ответ на второй вопрос)
Код
lua_unlock(L);
n = (*f)(L); /* do the actual call */
lua_lock(L);
3. Обратите внимание, что лок нигде не выпускает. На самом деле есть исключения, выпускает и тут же захватывает ровно в трех местах, после newtable, pushcclosure и concat, что в целом картины не меняет, их можно рассматривать как заинлайненные сишные функции.
На практике - попробуйте приведенный выше скрипт. В нем вызываются math.sqrt - сишные. Можете заменить на любые функции из qlua. А вот если заменить на примитивные операции, дающие только байткод, то квик зависнет. Например (квик придется прибивать, будьте готовы)
Код
local run = true
local nshow = 0
function OnAllTrade()
if nshow < 10 then
PrintDbgStr('OnAllTrade')
nshow = nshow + 1
end
end
function dummy(i)
local a = 1
for i = 1, 1000000 do a = a + i end
end
function main()
PrintDbgStr('Before loop')
for i = 0, 10000000 do
dummy(i)
end
PrintDbgStr('After loop')
end
Пользователь
Сообщений: Регистрация: 30.05.2020
11.02.2021 11:26:36
Цитата
Anton написал: байткод всегда выполняется под локом
Пока выполняется байткод (в любом потоке) сам QUIK залочен?
Цитата
Anton написал: Арке надо было только реализовать lua_lock/lua_unlock
А зачем понадобилось их реализовывать? Ну выполнялись бы потоки параллельно. А то так стопорится скрипт на каждом шаге, переключаясь то на один поток, то на другой.
Пользователь
Сообщений: Регистрация: 30.05.2020
11.02.2021 11:48:50
Цитата
Незнайка написал: Пока выполняется байткод (в любом потоке) сам QUIK залочен?
Ну да, ваш же тест это и подтверждает. Просто это было не так очевидно в скриптах, где байткод перемежается с си-функциями. Не далеко от QPILE ушли
Пользователь
Сообщений: Регистрация: 21.08.2015
12.02.2021 07:24:18
Цитата
Незнайка написал: Пока выполняется байткод (в любом потоке) сам QUIK залочен?
Когда в мейне байткод выполняется, квик не залочен. Но если квику нужно вызвать колбек, он будет ждать, пока появится "дырка" в мейне, чтобы захватить лок. Пример выше это может показать, если его изменить (убрать колбек и запускать цикл в мейне с задержкой).
Цитата
Незнайка написал: А зачем понадобилось их реализовывать?
Иначе любое обращение к луа из двух потоков одновременно ломало бы стек луа и вызывало крэш. Без локов можно было бы сделать, если бы мейн был отдельным скриптом, как выше swerg предлагал, но такой мейн малофункционален был бы сам по себе, ничего квикового из него нельзя было бы трогать.
Пользователь
Сообщений: Регистрация: 21.08.2015
12.02.2021 07:57:28
Цитата
Anton написал: ничего квикового из него нельзя было бы трогать
С этим, впрочем, погорячился, много чего таки можно было бы трогать.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
12.02.2021 22:01:53
Цитата
Anton написал: А вот если заменить на примитивные операции, дающие только байткод, то квик зависнет.
В 7-м квике не зависает даже более примитивный код:
Код
local run = true
function main()
while run do end
end
function OnAllTrade(alltrade) end
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
13.02.2021 09:48:05
Цитата
Старатель написал: В 7-м квике не зависает даже более примитивный код:
Мне все лень было проверить, но вот тоже такое впечатление, что в Lua 5.1 более грамотно были сделаны локи многопоточности. А в 5.3 совсем халтуру какую-то сделали.
Пользователь
Сообщений: Регистрация: 25.09.2020
13.02.2021 11:39:17
swerg, Это основной закон программирования, действующий почти для любого софта: самая удачная версия примерно третья, далее идёт загаживание продукта всяким дерьмом, и он медленно умирает. То же с книгами (достаточно вспомнить хотя бы "Робинзона Крузо" с его дурацкими "продолжениями"), с фильмами (не говоря уже про сериалы), с операционками (MS-DOS 3.3+Win-95+NT4/5+всё остальное дерьмо), с браузерами (здесь уже буквально все версии изуродованы до уровня половой тряпки) и со всем остальным. У гениев чуть иначе: "Бетховен написал три симфонии: первую, пятую и девятую".
написал: В 7-м квике не зависает даже более примитивный код:
Мне все лень было проверить, но вот тоже такое впечатление, что в Lua 5.1 более грамотно были сделаны локи многопоточности. А в 5.3 совсем халтуру какую-то сделали.
По всей видимости в 5.1 на каждой итерации цикла вызывались lua_unlock/lua_lock. А в 5.3 этого нет, если в цикле только байткод, что значительно уменьшает время вычислений таких циклов. Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах. Т.ч., нельзя назвать эти изменения в 5.3 "халтурой."
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 12.05.2020
20.04.2021 18:58:02
Цитата
Старатель написал: Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
То, что предлагает Старатель, наверное, имеет смысл реализовать в самом 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); }
Пользователь
Сообщений: Регистрация: 12.05.2020
20.04.2021 21:05:35
Цитата
Старатель написал: Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
То, что вы предлагаете, я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде. При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания. Ваше предложение легко реализуемо в QLua.
Пользователь
Сообщений: Регистрация: 30.05.2020
24.04.2021 20:56:37
Цитата
Anton написал: Когда в мейне байткод выполняется, квик не залочен.
Байт-код в мейнах нескольких скриптов выполняется параллельно?
Пользователь
Сообщений: Регистрация: 12.05.2020
24.04.2021 22:29:06
Цитата
Незнайка написал: Байт-код в мейнах нескольких скриптов выполняется параллельно?
Да. Но, основной поток QUIK, обслуживающий колбеки и таблицы QUIK (это не таблицы Lua) один. Если он блокируется в каком-либо скрипте, то перестает обслуживать остальные скрипты.
Пользователь
Сообщений: Регистрация: 31.08.2021
31.08.2021 19:49:55
Очень интересно, но ничего не понятно. А если версия 9.1.3.11, что тогда? И при загрузке выходит сообщение о том, что что-то там не догрузилось?
Пользователь
Сообщений: Регистрация: 11.09.2021
11.09.2021 10:29:04
Добрый день,
Подскажите пожалуйста, можно ли заказать скрипт для quik на этом форуме? Не противоречит правилам? Не увидел подходящей рубрики.
Подскажите пожалуйста, можно ли заказать скрипт для quik на этом форуме? Не противоречит правилам? Не увидел подходящей рубрики.
Кто может помочь со скриптом - просьба написать в Телеграмм aleksandr52019 - в ответ отправлю краткое ТЗ, договоримся о стоимости разработки.
Пользователь
Сообщений: Регистрация: 05.05.2017
10.02.2022 14:39:37
Нужна помощь знатока Луа для переделки коннектора старой версии Луа под новую библиотеку 5.3
Пользователь
Сообщений: Регистрация: 27.01.2017
15.12.2023 14:14:06
Раз уже здесь писали об ошибках потоков... Поймал ошибку, видимо ошибка потоков. Версия 11.0.0.92, lua 5.4
Обрыв связи, восстановление. Заново приходят все коллбеки с начала сессии до момента разрыва связи (здесь сразу вопрос - как бы это отключить?). В этот момент алгоритм находиться в цикле, перебирая некую таблицу. По логу вижу, что есть сообщение колбека, есть сообщения из цикла. И в какой-то момент цикл разрушается - получает данные из другой области памяти. Итеративная переменная 10, а получены данные по индексу 20, например. Или еще хуже - получены данные из совсем другой таблицы.
Воспроизвести не могу, но явно что-то случилось с стеком, при работе двух потоков.
Пользователь
Сообщений: Регистрация: 30.01.2015
16.12.2023 09:04:15
Надо обрабатывать как Reset, т е аналогично начальному соединению с сервером. Можно при этом учитывать учитывать принятые данные, чтобы не грузить все. Ситуация штатная. Ошибка, если не реализована обработка такого события.
