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

Ошибка в строке getinfo(1)

Никто и не обещал, что ошибка появляется всегда и сразу.
Можно запустить несколько копий скрипта, как тут, сделать перезаказ обезличенных сделок...
В общем, ошибка именно в этом коде и именно в этом месте присутствует. А как гарантированно воспроизвести - без понятия. Надо смотреть сорцы, откуда там nil.

Старатель, вопрос-предположение, у вас всегда параллельно со скриптами работает хоть один луа-индикатор?

Ага, спасибо. Закралась было мыслЯ, но нет )

Здравствуйте, Старатель,

Ваше сообщение получено, проблема изучается. Постараемся в ближайшее время дать ответ.

Старатель, добрый день!

К сожалению, нам не удалось понять причину проблемы. Рекомендуем использовать терминал версии 8.11 и Lua 5.4.
Приносим извинения за причинённые неудобства.

Касательно последнего сообщения, ответим немного позже.

Здравствуйте, Старатель.

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

Артем, добрый день!

Никакого патча виртуальной машины Lua не выполнялось.
Вся многопоточность реализована исключительно нативными средствами самого Lua.

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

Напоминаю, что каждое "ядро" это отдельный физический процессор. В домашних компьютерах как правило имеется всего 1 сокет и все процессоры монтируются на одном куске кремния, так что принято думать будто плата, на которой смонтировано десяток процессоров, это монолитный "процессор", а "ядра" это так, эфемерное понятие. На рабочих станциях и серверах распространены платы с 2, 4 и более сокетами под процессоры, и каждый процессор зачастую состоит из нескольких раздельных чипов, это проливает некоторый свет на идею многоядерности.


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

QUIK v.8.13.0.106, Lua 5.4

Очередная ошибкаСкрипт:

Скрытый текст

Код Queue = {   new = function (self)     return setmetatable({first = 1, last = 0}, {__index = self})   end,   push = function (self, v)     local last = self.last + 1     self[last] = v     self.last = last     return last   end,   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   end,   size = function (self)     return self.last - self.first + 1   end } local OnAllTra des = Queue:new() local function f(alltrade)   ...   OnAllTrades:push(alltrade)   ... end function OnAllTrade(alltrade)   ...  -- Во время ошибки параллельный поток находился где-то здесь   f(alltrade) end local run = true function main()   while run do     ...     if OnAllTrades:size() > 0 then      local alltrade = OnAllTrades:pop()  -- Тут ошибка "attempt to call a nil value (method 'pop')"      ...     end   end end

Queue работает годами в разных скриптах. И (условно) раз в год (или реже) скрипты ругаются на nil. Было в 7-й или 6-й версии квика. Какое тогда было сообщение об ошибке не помню.

Скрытый текст
И ещё претензия к code highlighter на форуме: в строке 24 Код local OnAllTra des = Queue:new() он зачем-то добавляет пробел внутри слова

Старатель, добрый день!

Проблему с code highlighter починили, можете проверять.

QUIK 9.1.0.63, Lua 5.4
Сегодня в коде (в main)выскочила такая ошибка:

Старатель, добрый день!

Описанные проблемы изучаются. Постараемся в ближайшее время дать ответ.

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

И?

  Очередь не моя, а разработчика QUIK.
  Мне не известно как вы обрабатываете обезличенные сделки (сколько это может занимать ресурсов ПК), поэтому я запустил тест для проверки времени выполнения потокобезопасных функций реализации только очереди:


  10000 обращений (запись, чтение, удаление) за 500 миллисекунд.
Понятно, что тест искуственный (без взаимодействия с колбеками), но какое то представление о скорости работы очереди и допустимой ее длине он дает.
Заметного роста памяти QLua я не заметил.

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

==========================
  А что же ситуации время от времени возникают?

 Вы имеете ввиду, что для записи и чтения в очередь используются свои указатели и, я бы с вами согласился, если бы не существовал общий объект, в котором это происходит (таблица хранения очереди в которую вставляются и из которой вычеркиваются элементы очереди). Вы уверены, что работа с таблицей при изменении ее структуры в Lua реализована потокобезопасно? Где это написано?

Разработчики ARQA, как я помню, утверждали с самого начала, что примитивные переменные и таблицы Lua не портятся при параллельном их изменении из разных потоков с помощью атомарных операций присваивания. Другое дело, что для таблиц это на самом деле может быть не так. Функции типа table.sinsert, table.sremove и т.п. пришлось вводить, т.к. они не атомарные и занимаются сдвигом внутренних элементов. Все ли подобные неатомарные штуки были "выловлены" разработчиками ARQA -- неизвестно. Если не все, то единственный адекватный вариант -- это создавать структуру в потоке коллбэков, потом table.sinsert, а в main-потоке делать table.sremove.

Теперь про "пропажу" функции pop(). Не исключаю, что время от времени терминал QUIK или операционная система занимаются неким "переносом данных внутри своей памяти" (например, при сборке мусора) во время которого оказывается, что функция pop ещё не определена (не успели её перенести) в новом месте, а её вызывают из другого потока. Но это уже мои домыслы.

1. Для устранения вашей конкретной ситуации, возможно, подойдет вариант реализации очередей, приведенный в моем комментарии https://forum.quik.ru/messages/forum10/message57219/topic6198/#message57219
2. Вообще, существует сравнительно несложный вариант заметно улучшить QLua (сделав его однопоточным для скриптера) без изменения его внутренней архитектуры:
1) добавить в API QLua функцию <задание схемы обработки колбеков>, которую скриптер может (но не обязательно) вызвать в начале своего скрипта с параметром задания схемы;  если эта функция не вызвана, то колбеки обрабатывыются так, как это делается сейчас по старой схеме;  дополнительно, в этой функции можно бы задавать версию Lua, а возможно и еще что-нибудь;  при задании новой схемы, внутри QLua автоматически реализуется схема взаимодействия main с колбеками через две потокобезопасные эффективные очереди (как обеспечить их эффективность, наверное, понятно), одна из которых обслуживает колбеки фондового рынка, а вторая, колбеки событий таблиц QUIK, созданных скриптером;
2) при работе по новой схеме обработки колбеков, в API QLua добавить еще две функции: <функция подписки на события фондового рынка> и <функция подписки на события пользовательских таблиц >; в этих функциях скриптер может, в виде списка (в таблице) подписаться на события в соответствии с существующими именами колбеков;  реализация подписки разработчиком QUIK может быть сведена к автоматическому созданию (скрытых) от пользователя функций колбеков, вызываемых, как это делается сейчас, и записывающих свои параметры с добавлением «от кого параметры» в соответствующие очереди;
3) для работы с очередями по новой схеме в API QLua добавить две функции чтения (?возможно также и выполнения некоторых дополнительных функций), соответственно очередям;  при чтении очередей в считываемой таблице передаются: <имя события>, <время записи в очередь>, <параметры в том виде, как они описаны, в существующих колбеках>.
   При работе по второй схеме, QLua для скриптера становится однопоточным и снимаются многие сложные проблемы. Причем, остается возможность не затрагивать и тех скриптеров, которые по тем или иным причинам не станут уходить от старой схемы.
----
 Общая схема работы скриптера в новой схеме обработки событий QUIK.
<Заказывается новая схема обработки событий >
<Выполняется подписка (вместо написания функций колбеков) на обрабатываемые события QUIK>
<В функции main, в цикле  читаются две очереди и обрабатываются считанные параметры событий>
-------
 Мною была описан некий, как мне представляется, не сильно сложный вариант реализации избавления QLua от проблем параллелизма, связанных с его существующей реализацией.

Не смотря на то, что сам тест бестолковый, но холостой цикл за 0,5 сек не слишком ли много?

Таблица из 1000 строк длиной 10 байт каждая. Какой "рост" вы рассчитывали увидеть в таком тесте?

Это не моя ситуация, а разработчиков QLua ))
И не увидел в вашем комментарии каких-то существенных отличий касательно использования метода pop().
Больше похоже на спам вашего  OS_...

TGB, слишкоммногабукв, не обратил внимание на цикл



Это уже пусть представители Арки комментируют, насколько безопасными являются действия типа
и код в сообщении #24 в частности.

TGB,
https://forum.quik.ru/messages/forum10/message57185/topic5823/#message57185
Это ваше сообщение?