Кривые шибки в QLua

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

Добрый день,

Мы рекомендуем отказываться от использования Lua 5.3 и переходить на Lua 5.4. Какие-либо доработки в Lua 5.3 не планируются.

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

QUIK 9.4.0.130, Lua 5.4


debug.getlocal() выдала следующие значения локальных переменных на уровне стека:

Для информации: параллельно работали ещё два скрипта. В одном из них в это время за 15 мс (минимальный квант) прошли следующие события: OnParam, OnQuote и 4 х OnOrder

Os.date есть в конце концов прямой вызов сишной функции и аозможно  win api Неправильно работать оно не может.

Если возникают проблемы, дело не в os.date, а в чем то другом. Испорчен стек вызовов, проблемы синхронизации или что угодно ещё. Грешить на луа не имеет смысла.

Не часто. Примерно с такой же частотой, как выходят релизы самого квика.

В данном случае ошибка возникла в main. Были ли подобные ошибки в колбеках сложно сказать, поскольку скрипт не останавливается при ошибках в колбеках, и их можно запросто не заметить.

while

Не представляю как это сделать.


Что-то мне подсказывает, что nil вернул tonumber, см. значения локальных переменных тут и 2-ю ошибку тут.

QUIK 9.3.3.3, Lua 5.4


В какой-то момент возникает ошибка "table index is nil".
Что-то не так с tonumber?

В данном конкретном скрипте другой поток массива queue не касается вообще.

Вот простой кодЕсли его запустить, то length = 5.
Если закомментировать a[4]  length = 3.
Если закомментировать a[2] или a[3], то сразу или с какого то раза length = 5.
Я не знаю, почему у меня так, но если у Вас так же, то #a работает не правильно.
Соответственно, Ваш цикл  перебирает и элемент массива который nil
Попробуйте внутри цикла сделать message на каждый queue[i].quantity что бы в этом убедиться(или не убедиться)

 Присоединяюсь.
----
 Дело в том, что стакан обслуживается в потоке отличном от main и может быть ситуация, что при чтении таблиц bid/offer и их проверки на существование они есть, но при обращении к ним они удалены в потоке обслуживания стакана. Но, конечно, желателен разъясняющий комментарий поддержки QLua.

    Вот и пусть это подтвердит поддержка. В любом случае разработчик QLua должен обеспечить возможность корректной работы со стаканом.

Вы это сами можете проверить, сохранив стакан в переменную. Состояние этой переменной будет статичным.

Все работает правильно.
Чтобы проверить это набираем Ваш пример в Scite -редакторе текста со встроенным отладчиком версия
вот ваш скрипт:
Если его запустить, то length = 5.
-----------------
a[1]=1
a[2]=3
a[3]=5
a[4]=7
a[5]=9
a[6]=nil
length=5
>Exit code: 0
>D:/lua54/lua54.exe -e "io.stdout:setvbuf 'no'" "test_.lua"
=====================
Если закомментировать a[4]  length = 3.
a[1]=1
a[2]=3
a[3]=5
a[4]=nil
a[5]=9
a[6]=nil
length=3
>Exit code: 0
==========================
Т е QLUA  не виновата
__________________
В документации на Lua Вы можете прочитать, что
длина массив #a  - не является действительной длиной, если в массиве есть дырки - nil
--------------------------


[CODE][/CODE]

 Иногда вы отвечаете правильно , но, почти всегда, длинно. Зачем вы цитируете комментарии полностью?
  Я тут с друзьями поспорил на бутылку хорошего коньяка, которую мы, конечно же, вы-пьем вместе.
  Первый друг утверждает, что вы не способны выделить фрагмент текста и потому всегда копируете весь комментарий, на который есть ваша реакция.
  Второй утверждает, что вы интеллектуальный спамер-бот, котрый генериhetn тексты иногда похожие на то, что мог бы выдать посредственный IT- специалист.
  Я же думаю что вы человек, которому платят за то, чтобы вы переполнили базу форума.
       Большая просьба к вам: разрешить наш спор и написать кто из нас прав   , чтобы мы смогли, наконец, «раздавить» вожделенную бутылку.

И давно getParamEx стала потоконебезопасной?

main абсолютно по барабану когда и сколько было вызовов колбеков.
Если состояние таблицы сохранено в переменную,
то даже через час, день, год... её состояние не изменится. main выведет именно то, что сохранили в переменной.

Если такое случится, то, однозначно, - это зона ответственности разработчика QLUA.

Я думаю, что описанные здесь ошибки (attempt to compare number with nil, tonumber вернул nil и т.п.) есть именно ошибки синхронизации (подобные вещи нередко встречаются и у меня). Места возникновения этих ошибок достаточно очевидны: коллбеки и обращения к таблицам QUIK, т.е. getParamEx, getDepoEx, GetCell и всё такое прочее, причём именно get, в не set - эти ошибки мало интересны. Любая из этих тварей может в любой момент вернуть nil - иногда так, что и сам скрипт вылетит. Надежды на то, что когда-либо хотя бы часть этих ошибок будет исправлена "на стороне Квика" лично у меня нет ни малейшей, так что бороться с ними придётся "подручными средствами". Такими средствами являются:

1. Минимизация использования всего вышеперечисленного: всё, что может сделать сам скрипт, должен делать сам скрипт. В частности, настоятельно рекомендую отказаться от всех "подписных изданий" (стаканов или даже свечей) - это источник головной боли, тормозов и дезинформации. У меня из коллбеков используется только OnTrade и OnStop, каждый из которых в своё время попортил мне немало крови, а OnTrade до сих пор продолжает это делать.

2. Как можно реже обращаться к таблицам Квика. У меня это только "orders", причём обращение к ней через getItem происходит лишь в некоторых экзотических случаях снятия несработавших заявок (вряд ли больше десятка-другого раз за сутки). Кроме того, я обращаюсь (через GetCell и тоже очень редко) к своим таблицам, созданным Квиком, но только к одному из столбцов таблицы по тикерам (невидимому), только для того, чтобы определить "настоящий" ID строки, который не меняется, скажем, при изменении порядка следования строк в таблице после сортировки и только для определения, по какому именно тикеру должно быть вызвано контекстное меню.

3. Проверять на nil во всех таких "опасных" ситуациях - это, по крайней мере, не приведёт к вылету скрипта.

4. Минимизировать время работы коллбеков. Например, мой OnTrade с течением времени оброс всякими проверками до неприличия из-за маразматической и годами не исправляемой ситуации с приходом нескольких прерываний на одно событие, да ещё и вразнобой, а также необходимости учёта "левых" сделок, совершённых в обход скрипта. Похоже, здесь тоже идут какие-то наводки из-за того, что во время обработки коллбека ещё что-то происходит. Планирую максимально облегчить сам OnTrade и перенести основную обработку в прерывание по таймеру, которое фактически находится в потоке main.

5. Очень аккуратно относиться к программированию диалога, средств для организации которого в Lua практически нет. Я толком не понимаю, что там происходит в обработчиках, устанавливаемых по SetTableNotificationCallback, но тут иногда даже не скрипт вылетает, а сам Квик отвисает.

Ну и не обращаться к техподдержке с пожеланиями что-либо исправить: в лучшем случае, останется всё как есть.  

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

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

      Этот комментарий пишу, в основном,  для разработчика QUIK.

1. При открытии библиотеки base_funcs (Lua 5.4.1), в которой находится tonumber, все ее функции помечаются как С-функции. Это означает, что в программе Lua они выполняются в скобках:
lua_unlock(L);    Запуск C-функции;    lua_lock(L);
    Такие функции могут выполняться параллельно с исполнением  QLua-кода. Однако любые операции с использованием в них L, должны выполняться в синхронизирующих скобках:
 lua_lock(L);    Выполнение операций в L;     lua_unlock(L);
     При просмотре исходника функции tonumber (с учетом вызываемых в ней функций), я обнаружил, что в этой функции есть как минимум один фрагмент с использованием операций в L без синхронизирующих скобок (мои комментарии помечены в исходнике символами #####):

    Возможно, что-то я упустил, но пусть это проверит разработчик QUIK.
    ----------
2. Есть общая проблема в реализации стандартных функций Lua для многопоточного использования, описанная в моем комментарии: https://forum.quik.ru/messages/forum10/message57243/topic6555/#message57243
-------
3. Существует вариант построения архитектуры встраивания Lua в QUIK, в которой можно использовать однопоточный (нативный) Lua :
1)    вместо регистрации функций обратного вызова, регистрация соответствующих очередей событий (возможно, с теми же именами);  
2)    вместо sleep, использование служебной функции ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);
3) добавление функции чтения очередей событий (их параметров);
4) реализация функций интерфейса c QUIK в виде отдельного пакета dll, подключаемого в Lua.
      Подключение новых версий Lua станет в описанной выше архитектуре рутинной задачей. Исчезнут все проблемы, вызванные текущей многопоточностью QLua.

  У меня все это сделано.
Ключевым п.3 является:
и

Что такое (нативный) Lua ? Это Ваше изобретение?
---------------------------
Один тут "чистый" луа придумал, второй "нативный"
-------------------
Для изобретателей мусора :
================

Обратимся к Wiki

Машинный код (также употребляются термины собственный код, или платформенно-ориентированный код, или родной код, или нативный код — от англ. native code) — система команд (язык) конкретной вычислительной машины (машинный язык), который интерпретируется непосредственно микропроцессором или микропрограммами данной вычислительной машины.

==================

еще раз повторю для особо тупых:

нет ни чистого ни нативного Луа,

каждая команда байт-кода луа - это функция, написанная на языке C.

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

nikolz, для вас тут вопрос давно висит:

И давно getParamEx стала потоконебезопасной?
Если уж умничаете, то умничайте до конца. Либо признайте, что написали глупость.

    Не факт, что обнаруженная вами сложная ошибка (синхронизации) относится только к tonumber. Существующая реализация разработчиком Lua стандартных C-функций Lua (5.4.1) архитектурно не учитывает многопоточность использования Lua. Для выполнения любых операций в таких функциях с элементами, хранящимися в lua_State, надо было сделать доступным только API-C, но этого не сделано.  Выяснять потокобезопасность каждой такой функции, анализируя ее исходники это, конечно, не решение.
---------
 Когда обсуждаемая ошибка будет устранена разработчиком QUIK неизвестно. Поэтому конкретную проблему с tonumber вы, наверное, могли бы решить следующим образом:
написать в каком-нибуть своем C-пакете собственную, но потокобезопасную функцию tonumber_с, аналогичную tonumber, и в начальном запуске сриптов выполнять перегрузку tonumber = tonumber_с.   Здесь, правда, существует засада: возможно, при неявных преобразованиях строк в число будет вызываться прежняя (потокоопасная) функция.

Согласен. Поэтому сделал переопределение таким образом:
Вероятность возникновения nil не исключает, но значительно снижает.
Раннее уже приходилось делать подобные переопределения для функций getDepoEx, getFuturesLimit и getFuturesHolding.

Буду постепенно менять на явное преобразование через tonumber, если где в коде встретится неявное.

я немного влезу от скуки, без полного понимания обсуждения, извините, но о каких исходниках идёт речь?
в 5.4.2 Lua есть такой код

то есть эти "скобки" ничего не делают на самом деле.

и еще вы пишете что колбеки в текущей реализации не исполняются параллельно main. это действительно как-то так? main где-то приостанавливается? каким образом?