Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок

Страницы: Пред. 1 2 3 4 5
RSS
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Anton написал:
им, возможно, все понятно
Похоже, им все понятно. И это главное. Они разработчики QUIK. От них я вопросов не получаю (даже после моих неоднократных назойливых сообщений: а нет ли ко мне каких-либо вопросов?). С ними я готов обсуждать любые проблемы и они знают адрес моей почты.
 
.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
Прикрепленные файлы
Надо хотя бы уметь читать:

--------

Ответ поддержки.

Добрый день.
 
   Проблемой занимаемся, если будут дополнительно вопросы, то мы     сообщим.
   Извиняемся за долгий разбор, постараемся ответить, как можно скорее.

 
Цитата
s_mike@rambler.ru написал:
Прикрепленные файлы  
  Взглянул еще раз и увидел что смешно.

За начальную фразу своего предыдущего комментария извиняюсь. В момент его написания мне было не до юмора.

 
В ветке «Изменения в работе с колбеками LUA в новой версии» https://forum.quik.ru/messages/forum10/message49848/topic5930/#message49848
появилось интересное сообщение:

Александр написал:
  Разработчики написали в письме:

   

Цитата

 

В ближайшей версии мы изменим   работу с коллбэками Lua. Ожидаем, что изменения исключат возникающую ошибку.    

Могли бы разработчики более подробно описать грядущие изменения?

Поддержка:

Добрый день,
Пока подробностей нет. Как выйдет новая версия это будет указано в списках изменений.

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

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

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

  Я не знаю точно, какие изменения будут, но попытаюсь дать прогноз (интересно, насколько промахнусь). А если промахнулся, то это мои предложения.

   Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:

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

   2)    вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);

   3)    добавление функции чтения очередей событий (их параметров).

   Эта схема реализует рекомендованную ARQU обработку параметров событий в main.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.

При этом проблема сбоев автоматической памяти QLua 5.3, о которой я писал не раз в ветке «Грядущие
изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и
сделок
» должна исчезнуть.

----

Добавление.

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

 
Появился QUIK 8.11.0.66:  https://arqatech.com/ru/support/files/quik-workstation/

1. С прогнозом возможных изменений в QUIKе я промахнулся и мои предложения по изменению архитектуры QUIK для повышения его устойчивости проигнорированы.
  За то добавился вариант QLua 5.4.1. Мне хочется это прокомментировать, но слов не нахожу.
2. Для QLua 5.3.5, на текущий момент, все написанное мною в этой ветке остается актуальным. QLua 5.4.1 не проверял, пусть «отлежится».
Мои комментарии для поддержки и разработчиков QUIK:
1) https://forum.quik.ru/messages/forum10/message51033/topic6053/#message51033
2) https://forum.quik.ru/messages/forum10/message51055/topic6053/#message51055
 
В 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.
  Реализованную схему обработки событий элегантной назвать трудно, но она позволяет сохранить существующий пользовательский интерфейс.
 
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

 
Цитата
Anton написал:
TGB , неправда. Если бы было правдой, в следующем скрипте между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' вклиниться не могло

 Правда.  При выполнении таких тестов (анализ выполнения потоков) необходимо для вывода сообщений вместо  message  использовать  PrintDbgStr. Сделайте такую замену и прогоните ваш тест заново. Для просмотра результатов используйте Dbgview.
     Я прогонял ваш тест (с предложенной вам заменой). Между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' не вклинилось.
 
Цитата
TGB написал:
Между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' не вклинилось.
Значит увеличьте длину цикла или усложните вычисления в dummy, цикл просто быстро закончился. Вы обнаружили, что на время вызова любой сишной функции (а не только sleep) луа снимает лок, и сделали неправильный вывод, подумав только на sleep. В качестве такой функции может выступить и message, как в примере, и любая встроенная в луа библиотечная функция, и любая функция 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 = 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 написал:
Теперь очевидно?
 Да.
 
Цитата
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.
 
Цитата
TGB написал:
Обкладывать синхронизацией все используемые сишные функции в однопоточном QLua для меня неожиданное решение.
А их никто и не обкладывал. Это не аркино решение, сам луа так устроен. Все очень просто, байткод всегда выполняется под локом, а когда надо вызвать сишную функцию, лок снимается и после возврата захватывается снова. Арке надо было только реализовать lua_lock/lua_unlock, все остальное уже готово. Тут хочу добавить, что если вы в своей длл определяете сишный колбек, то он тоже без лока выполняется (в отличие от луа-колбека). И это отличное место, где можно прострелить себе ногу.

Цитата
TGB написал:
Вообще, в однопоточном QLua можно было бы практически полностью отказаться от всякой синхронизации и от модификации исходного Lua.
Исходный луа практически не модифицирован, добавлены только колбеки, предусмотренные в луа для взаимодействия с хостом. Сама qlua.dll ничего не хачит, использует луа как положено через стандартный апи, что местами не очень эффективно, но идеологически правильно.

Насчет однопоточности - так можно было сделать с самого начала, теперь что-то переделывать, похоже, поздновато. И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое. Сравните с виндовыми очередями сообщений, где позиция мыши и нажатые клавиши сохраняются для каждого сообщения, какими они были на момент генерации сообщения, это вот пример, какие сложности возникают. И арке пришлось бы тоже подобным заниматься, закончилось бы полным дампом состояния, прицепленным к каждому сообщению. А как есть - вам дали колбек, квик вас ждет в колбеке, вы забираете то, что нужно именно вам и отправляете в мейн. Тоже не все гладко, кое-что все равно асинхронно даже в колбеке, но это мизер по сравнению с адом, который был бы с наглухо зашитыми в qlua очередями.
 
Цитата
Anton написал:
И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое.
  Это не является особенностью предлагаемого решения. Это относится и к существующей реализации.
 Вообще, это неустранимый фактор в системах реального времени, к которым относится и QUIK.
 
Цитата
Anton написал:
И у такого решения есть минус, на момент выборки сообщения в потоке скрипта общее состояние квика уже другое
  Дополнительно, насчет минуса?:
 5) так как, по появлению нового события, в предложенном решении выдается сигнал, по которому (если есть ожидание потока main  на операции sleep_q)  запускаются колбеки скрипта, то мы имеем более оперативную  реакция пользовательского потока main по сравнению с существующим решением, и описанный вами фактор, в предложенном решении менее значим;
 6) в этом решении на пользовательские колбеки нет никаких ограничений (связанных с нагрузкой основного потока обслуживания скриптов), кроме понимания, того, что выполнение колбеков делается в пользовательском потоке;
 7) и еще раз: любая синхронизация (для того, кто понимает) - это геморрой, порождающий трудно исправляемые ошибки (совершенно неожиданные), от которого, если есть возможность, следует избавляться.
 
Мой модифицированный тест управления автоматической памятью 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.
 
Цитата
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? Почему оттуда не скачать?
 
Цитата
TGB написал:
  выкладывать библиотеки импорта (.lib) функций Lua53.dll (Lua54.dll и т.д.), например, в папке хранения файла info.exe. Понятно, что такие библиотеки можно создать на основе файлов dll, но, наверное, не все пользователи знают, как это сделать. Эти библиотеки нужны при перетрансляции C-пакетов QLua при переходе на новые версии Lua

Я вот не помню как делать библиотеки импорта на память, но каждый раз просто-напросто загугливаю за 1 минуту пошаговый мануал, коих сотни; вот и всё.
Кто с помощью гугла не может сделать lib-файл из DLL - он, уж извините, и пакеты не перетранслирует. Даже при наличии lib-файла
 
Цитата
Anton написал:
байткод всегда выполняется под локом, а когда надо вызвать сишную функцию, лок снимается и после возврата захватывается снова. Арке надо было только реализовать lua_lock/lua_unlock, все остальное уже готово.
Т.е., весь луа-код, в т.ч. и сишные функции из qlua, не может выполняться одновременно в двух потоках?
Ну и зачем тогда нужно было городить весь этот огород с двумя потоками, если они всё равно не работают параллельно?

Вопрос к разработчикам: какие преимущества дала такая двухпоточная модель работы Lua-скриптов?
 
Цитата
Незнайка написал:
в т.ч. и сишные функции из qlua
Нет. Сишные функции - любые, из самого луа, из qlua, из пользовательской длл - выполняются без лока. Под локом только байткод. Конкретно в qlua все функции сишные, в самом луа библиотечные функции тоже все сишные.

Цитата
Незнайка написал:
Вопрос к разработчикам
Забегу-таки вперед паровоза. Без второго потока пользовательский мейн вообще нельзя было бы выполнить от слова никак. Были бы только колбеки, как в индикаторах.
 
Цитата
Anton написал:
Забегу-таки вперед паровоза. Без второго потока пользовательский мейн вообще нельзя было бы выполнить от слова никак. Были бы только колбеки, как в индикаторах.

На мой взгляд, задумка оказалась неудачной.
У разработчиков, очевидно, была необходимость сделать замену QPILE с его раз в секунду выполнением, причем в отдельном потоке. Для чего и была сделана main().
Но дальше началась мутная каша.

На мой взгляд, надо было сделать две категории скриптов Lua (помимо индикаторов):
1) Чисто событийный скрипт. С нем могут быть только обработчики событий. Срабатывает что-либо в нём только по событиям, в одном потоке (не обязательно основном, но в одном). Для особо скучающих добавить еще периодическое настраиваемое событие таймера, что просто.
2) Скрипт, выполняющий бесконечный цикл исключительно в отдельном потоке. Но опять же только в одном потоке, пусть и отдельном. Это будет просто полноценная замена QPile и радость любителям постоянно что-то колбась без остановки.

А вот замешивание в одну кашу двухпоточности в рамках одного скрипта лишь добавляет слишком сложных глюков, при этом постоянно получая кашу в анных, да еще и залезая в дедлоки порой. Никакой пользы при этом это не приносит совершенно, считаю.
 
Цитата
Anton написал:
Сишные функции - любые, из самого луа, из qlua выполняются без лока
Как можно в этом убедиться?

При вызове, скажем сишной функции из самого lua, сначала ставится lua_lock потом выполняется функция, затем lua_unlock
или в обратном порядке: lua_unlock - выполнение функции - lua_lock?
 
Цитата
Незнайка написал:
Как можно в этом убедиться?
1. Обратите внимание, что первое действие в lua_pcallk - захват лока. Любое выполнение луа из квика начинается через lua_pcallk.
2. Обратите внимание на ветку для light C function, в частности на строки (также ответ на второй вопрос)
Код
      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
 
Цитата
Anton написал:
байткод всегда выполняется под локом
Пока выполняется байткод (в любом потоке) сам QUIK залочен?

Цитата
Anton написал:
Арке надо было только реализовать lua_lock/lua_unlock
А зачем понадобилось их реализовывать?
Ну выполнялись бы потоки параллельно. А то так стопорится скрипт на каждом шаге, переключаясь то на один поток, то на другой.
 
Цитата
Незнайка написал:
Пока выполняется байткод (в любом потоке) сам QUIK залочен?
Ну да, ваш же тест выше это и подтверждает.
Просто это было не так очевидно в скриптах, где байткод перемежается с си-функциями. Не далеко от QPILE ушли  :what:
 
Цитата
Незнайка написал:
Пока выполняется байткод (в любом потоке) сам QUIK залочен?
Когда в мейне байткод выполняется, квик не залочен. Но если квику нужно вызвать колбек, он будет ждать, пока появится "дырка" в мейне, чтобы захватить лок. Пример выше это может показать, если его изменить (убрать колбек и запускать цикл в мейне с задержкой).

Цитата
Незнайка написал:
А зачем понадобилось их реализовывать?
Иначе любое обращение к луа из двух потоков одновременно ломало бы стек луа и вызывало крэш. Без локов можно было бы сделать, если бы мейн был отдельным скриптом, как выше swerg предлагал, но такой мейн малофункционален был бы сам по себе, ничего квикового из него нельзя было бы трогать.
 
Цитата
Anton написал:
ничего квикового из него нельзя было бы трогать
С этим, впрочем, погорячился, много чего таки можно было бы трогать.
 
Цитата
Anton написал:
А вот если заменить на примитивные операции, дающие только байткод, то квик зависнет.

В 7-м квике не зависает даже более примитивный код:
Код
local run = true
function main()
  while run do end  
end
function OnAllTrade(alltrade) end
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
В 7-м квике не зависает даже более примитивный код:
Мне все лень было проверить, но вот тоже такое впечатление, что в Lua 5.1 более грамотно были сделаны локи многопоточности. А в 5.3 совсем халтуру какую-то сделали.
 
swerg, Это основной закон программирования, действующий почти для любого софта: самая удачная версия примерно третья, далее идёт загаживание продукта всяким дерьмом, и он медленно умирает. То же с книгами (достаточно вспомнить хотя бы "Робинзона Крузо" с его дурацкими "продолжениями"), с фильмами (не говоря уже про сериалы), с операционками (MS-DOS 3.3+Win-95+NT4/5+всё остальное дерьмо), с браузерами (здесь уже буквально все версии изуродованы до уровня половой тряпки) и со всем остальным. У гениев чуть иначе: "Бетховен написал три симфонии: первую, пятую и девятую". :smile:  
 
Цитата
swerg написал:
Цитата
Старатель написал:
В 7-м квике не зависает даже более примитивный код:
Мне все лень было проверить, но вот тоже такое впечатление, что в Lua 5.1 более грамотно были сделаны локи многопоточности. А в 5.3 совсем халтуру какую-то сделали.
По всей видимости в 5.1 на каждой итерации цикла вызывались lua_unlock/lua_lock.
А в 5.3 этого нет, если в цикле только байткод, что значительно уменьшает время вычислений таких циклов.
Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
Т.ч., нельзя назвать эти изменения в 5.3 "халтурой."
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
 То, что предлагает Старатель, наверное, имеет смысл реализовать в самом 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);
    }
 
Цитата
Старатель написал:
Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
  То, что вы предлагаете, я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде.
При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания.
  Ваше предложение легко реализуемо в QLua.
 
Цитата
Anton написал:
Когда в мейне байткод выполняется, квик не залочен.
Байт-код в мейнах нескольких скриптов выполняется параллельно?
 
Цитата
Незнайка написал:
Байт-код в мейнах нескольких скриптов выполняется параллельно?
  Да.
Но, основной поток QUIK, обслуживающий колбеки и таблицы QUIK (это не таблицы Lua) один. Если он блокируется в каком-либо скрипте, то перестает обслуживать остальные скрипты.
 
Очень интересно, но ничего не понятно.
А если версия 9.1.3.11, что тогда? И при загрузке выходит сообщение о том, что что-то там не догрузилось?
 
Добрый день,

Подскажите пожалуйста, можно ли заказать скрипт для quik на этом форуме? Не противоречит правилам?
Не увидел подходящей рубрики.
 
Цитата
Александр написал:
Добрый день,

Подскажите пожалуйста, можно ли заказать скрипт для quik на этом форуме? Не противоречит правилам?
Не увидел подходящей рубрики.
Кто может помочь со скриптом - просьба написать в Телеграмм aleksandr52019  - в ответ отправлю краткое ТЗ, договоримся о стоимости разработки.  
 
Нужна помощь знатока Луа  для переделки коннектора старой версии Луа под новую библиотеку 5.3
prmt@yandex.ru
 
Раз уже здесь писали об ошибках потоков...
Поймал ошибку, видимо ошибка потоков. Версия 11.0.0.92, lua 5.4

Обрыв связи, восстановление. Заново приходят все коллбеки с начала сессии до момента разрыва связи (здесь сразу вопрос - как бы это отключить?). В этот момент алгоритм находиться в цикле, перебирая некую таблицу.
По логу вижу, что есть сообщение колбека, есть сообщения из цикла. И в какой-то момент цикл разрушается - получает данные из другой области памяти. Итеративная переменная 10, а получены данные по индексу 20, например.
Или еще хуже - получены данные из совсем другой таблицы.

Воспроизвести не могу, но явно что-то случилось с стеком, при работе двух потоков.
 
Надо обрабатывать как Reset, т е аналогично начальному соединению с сервером.  Можно при этом учитывать учитывать принятые данные, чтобы не грузить все.  Ситуация штатная. Ошибка, если не реализована обработка такого события.
Страницы: Пред. 1 2 3 4 5
Читают тему
Наверх