Отладка QUIK 8.13

Я пытаюсь помочь решить наши с вами проблемы потокобезопасности API QLua работы с QUIK.
 Если синхронизация функций API реализована так:
то тех "плавающих" результатов, которые описаны в ветках:
1) Опять ошибка получения кол-ва ордеров скриптом https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе https://forum.quik.ru/forum10/topic6526/ .
по моим представлениям, быть не должно.
 Пусть мне кто-то объяснит, что я ошибаюсь.

TGB, Добрый день, Действительно, в ПО QLUA есть ошибка одновременной работы скриптов использующих лимиты. Мы исправим её в очередном обновлении ПО. Приносим извинения за причинённые неудобства.

Всё же вставлю свои "пятькопеек".
В текущей реализации QLua (5.3/5.4) задача легко решаема на уровне пользовательского скрипта методом, предложенным мной выше, что позволяет при необходимости снять блокировку в любом месте цикла.
Это позволяет скриптеру писать байткод-циклы (в текущей версии QLua 5.3/5.4), выполняющиеся атомарно (читай потокобезопасно).
При реализации вашего пожелания на уровне QLua скриптер лишится такой возможности.

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

TGB,
как вариант, или многоуровневые таблицы, или одно событие может менять состояние нескольких таблиц...

Держите и вы от меня "шайбу":

Какие ограничения накладывает отсутствие "Счетчик_для_переключения_State"?

  Некоторое уточнение моих представлений относительно ценности любых средств разработки программ (в том числе QLua).
   Я уже в одном из своих комментариев отмечал:
  что когда обсуждаются любые средства разработки программ, вопрос «нельзя ли это сделать по-другому?» бессмысленен, по той причине, что все можно сделать по-другому. Вопрос по существу может быть таким: «упрощают ли предлагаемые средства разработки программ жизнь пользователя или нет? И в какой степени?».

 Блокировку потоков длинным участком кода пользователя на "чистом" Lua, наверное, трудно назвать функционалом QLua.

Часто ли вам требовалось использовать этот вариант?


Я не против, если скриптер будет иметь контроль, например заданием переменной из скрипта: если счетчик задан, то снимать лок, через заданное количество циклов. Если не задан, то - без изменений. Как то так.

  Мне кажется, с предупреждением, вы опоздали (как всегда, "все украли до нас" ).
 ARQA уже создала и использует форк луа:
  1) исходники Lua были изменены для обеспечения многопотоковости QLua (смотрите мой комментарий https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696);
  2) сравните размер кода Lua (~300 кб) с размером кода QLua (более 500 кб).

1.
  То, что я предложил очень конкретно, работает (прочитайте эту ветку сначала).
Где ваше предложение достичь того же самого без изменения кода Lua?

2. Здесь, как я понимаю, мы с вами обсуждаем конкретное предложение, протестированное  на моем стенде:
  Вместо того, чтобы сделать конкретные замечания по выше предложенному, вы пускаетесь в филосовские рассуждения о том, после какой, внесенной в исходники Lua запятой, считать его «форк луа».  
   Причем, напомню вам, что по вашему же предложению (кстати, поддержанного в комментариях мною) были внесены разработчиком QUIK заметные изменения в обработку исключительных ситуаций Lua.  Наверное, вы ответите, что изменения в обработку исключений не делают Lua «форком луа» .

То есть, вы вполне удовлетворены тем, что QLua является «форком луа» (если вы отвергаете все остальное, приведенное мною в обоснование того, что QLua, похоже, форк ) хотя бы по причине:
И тогда что это:

 Ну, не я же начал про  форки.  А ответил потому, что подумал, что, вдруг, узнаю что-то новое.

Насчет околесицы не согласен, почитайте наше с вами общение, начиная с комментария: https://forum.quik.ru/messages/forum10/message54757/topic6356/#message54757

  Это уже интересно.
Опишите как такие переключения вам мешают. Мне они никак не мешаю.

  Все, что вы написали (включая ссылку) как-то декларативно и нет конкретики. Типа, это не надо делать, потому что не надо.
 Но в вашем комментарии есть фразы, на которые я попытаюсь ответить или задать вопросы.
1.  Каким образом что-то будет ломаться, если будут переключение потоков внутри «чистого» кода Lua (байт-кода)?
---
 Сейчас переключение потоков в QLua возможно, и выполняется при вызове в скрипте C-функций, которых в рабочем скрипте обычно достаточно много (начиная со sleep). И при этом ничего не ломается.
  Что изменится в описанном выше качественно, если будут переключения на участках байт-кода? Ничего!  Вы же можете, без проблем, в существующий скрипт добавить, для своих целей, новые вызовы C-функций внутрь существующего байт-кода и это нормально.
 Предлагаемый мною вариант переключения внутри байт-кода это, по сути, добавление очень эффективного вызова «пустой», ничего не делающей C-функции через определенный интервал выполнения команд байт-кода. Это обеспечивает возможность переключения потоков внутри байт-кода и устранение блокировки потоков длительными фрагментами байт-кода.
  Интервал вызова «пустой» C-функции может быть таким (например, 1000), что дополнительные «окна» переключения потоков  практически никак не влияют на скорость выполнения скрипта (это проверено мною экспериментально). При этом разработчику скрипта. дополнительно к тому, чем занимается его скрипт, ничего делать не надо.

2.  Что это даст всем (скриптерам)?
 Сейчас, если в скрипте выполняется  длительный участок байт-кода main,  то на время его выполнения, блокируется выполнение основного потока, обрабатывающего колбеки всех запущенных скриптов пользователя и обслуживающего события таблиц QUIK. Все аналогично, если описанное выше, происходит в функции, вызванной в колбеке.
 -----
Для демонстрации выигрыша скриптера от реализации обсуждаемого предложения рассмотрим, например, следующую ситуацию.
У пользователя запущено два скрипта (почему бы нет, они будут выполняться в разных потоках):
первый скрипт продуктив, который реально торгует на рынке (обрабатывает колбеки);
второй скрипт продуктив, который тоже реально торгует на рынке (обрабатывает колбеки).
  Если во втором/первом скрипте в какой-то момент времени  будет обрабатываться длинный байт-код в main и при этом в нем вызовется колбек, то поток обработки колбеков всех скриптов будет заблокирован. При этом перестанут обслуживаться и колбеки первого/второго скрипта. Это может произойти неожиданно и в самом неподходящем месте и породить неприятные последствия для торгующего. Этого ожидает пользователь? Надо ли скриптеру, при каждой редакции своих скриптов анализировать свой код на возможность возникновения описанной ситуации или других похожих?
----
 Если бы было реализовано то, что я предлагаю, то описанных выше блокировок не было бы.
 Кто-то скажет, что описанный выше пример надуманный, редкий и так далее. Но, те, кто разрабатывал более-менее серьезные программы, наверное, понимают, что если есть баг в программе, то рано или поздно он может проявиться.
3. И вопрос Антону: все-таки, интересно, какую конкретную функциональность в своих разработках вы реализуете, использую блокировку потоков выполнением длинных участков байт-кода?

  Пусть это и демонстрирует реальная жизнь

Точно также, если переключение (! оно не может возникать внутри команд Lua-машины, а только между ними) в байт-коде вдруг возникнет после tid = nil, но до DestroyTable, то оно снимает лок, мейн видит вместо таблички нил и все правильно понимает. При этом исполнение кода в мейн не сможет блокировать поток обработки колбеков и DestroyTable тоже успешно выполнится. В чем вы видите проблемы?

 Я помню, что в Qlua есть потокобезопасные функции, обеспечивающие функциональность критической секции и нет проблем использовать их в представленном вами примере (вы с этим сами можете разобраться и я не буду тратить время на то, как это можно сделать), Я только не очень понимаю зачем это может потребоваться в приведенном вами примере?
 Но дело обстоит еще проще. Если вы знакомы с документом разработчика QUIK «Использование Lua в Рабочем месте QUIK.pdf», то его в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков фондового рынка, которую можно распространить и на обработку колбеков событий таблиц QUIK. Если придерживаться этой схемы, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном. И не надо ни чем извращаться ни в одной строчке скрипта так как при этом он становится однопоточным (относительно основного потока обработки колбеков). Вы можете почитать комментарии, начиная с https://forum.quik.ru/messages/forum10/message56387/topic6356/#message56387 , в которых это обсуждается с демонстрацией кодов, рекомендуемых разработчикам QUIK.
  Если же в скрипте не используется схема обработки колбеков, рекомендованная разработчиком QUIK, то преобразование любого такого скрипта в функционально эквивалентный, но с рекомендованной схемой, элементарное.

 Похоже, примеры с вами можно бы было обсуждать бесконечно  
----
 Опять декларации и страшилки. Но это же можно бы было сформулировать короче: «Не тронь!»
Вы что, это не читали?:
  или вы убежденный противник решения разработчика QUIK, приведенного в указанном фрагменте текста?
  Попытаюсь сформулировать, то, что написано там более понятно и короче.
  Если использовать то, что написано в этом фрагменте, то никакой синхронизации с потоком, обрабатывающем колбеки  не требуется. Ни нужны никакие костыли. Не требуется многочасовой анализ кода скрипта на атомарность/неатомарность, (ворк/неворк   ). Причем, это справедливо как для существующих версий QLua, так и в случае реализации предлагаемого мною решения, устраняющего ошибку блокировки потоков длинными участками байт-кода.
 Сформулировать это еще короче я уже, наверное, не смогу  

Если вы это так поняли, то, придется, все-таки стоит пояснить.
  Конечно же, каждый разработчик может писать скрипты как хочет:
1) постоянно, после очередной редакции скрипта, анализируя код на его атомарность/неатомарность (марлезонский балет);
2) не заморачиваясь проблемама синхронизации с колбеками (вообще не зная что такое атомарность)
И это никак не связано с тем, останется ли блокировка потоков участками байт-кода (как это про-исходит сейчас) или это будет устранено.

Согласен.

Я уже думал, что наш диалог завершен, но вы пишите такие фантазийные, детективные тексты, что мне стало интересно.
 Где я такое написал?
Если вам кажется, что это находится в опубликованном мною коде, то укажите, где вы нашли такую закладку?

 Вы что, экстрасенс   ?
Я же просто представил протестированный на своем стенде (на котором в сое время тестировал исправление ошибки синхронизации QLua) код исправления блокировок потоков длинными участками байт-кода. Это короткие правки в 4-х местах кода QLua. Их можно изучать визуально, проверять экспериментально, искать в них "до посинения" закладки.

 Вот и замечательно! Хорошо построенная программная система должна быть защищенной.

 И это предлагается вместо "прозрачных" правок в 4-х места кода, вносимых туда в течении пяти минут? Как-то очень сложно (я бы до такого не додумался   ) и вот уж куда удобнее вставлять закладки.

Вообще ни о чем не говорит.
Сильно зависит как от версии компилятора, от ключей компиляции, так и от режима линковки стандартной библиотеки.

Anton , зачем вы все время требуете продолжение «марлезонского балета»?
Ну хорошо, продолжим.

  На самом деле это проблема не моя. Для себя эту проблему я решил достаточно давно (аж в 2019г.,  когда разработал свою систему создания торговых роботов в QUIK). Утомлять вас здесь тем, как это у меня решено, я не буду.

    Ну, наверное, вам бы стоило протестировать (на интервале, хотя бы, трех суток) предложенное вами решение у себя. И изложить его здесь с той же детальностью, как это сделал я.
 Наверное, из двух работающих решений можно бы выбрать то, которое лучше.
    Возможно, я бы и сам отказался от своего предложения. Я же не «упертый» и с дельными замечаниями, сделанными мне, легко соглашаюсь (можете посмотреть некоторые мои комментарии). А, кстати, почему вы так упорно боретесь против «форка lua»? Как то это сильно смахивает на борьбу за невинность девушки, которая уже больше года замужем.

Этого делать не надо, а лучше поищите закладки в моем коде   .

Что вы фигнёй маетесь, господа? Я вот тоже "разработал свою систему создания торговых роботов в QUIK", хотя появился здесь (и написал свою первую строчку на Lua) в сентябре прошлого года. Скрипт свой я уже и не помню, когда правил в последний раз. В ём сейчас 16 функций, включая main и прочие OnStop, объём кода менее 20 кило, и на все "версии компилятора, ключи компиляции и режимы линковки" мне давно пилювать с высокой колокольни. Кажется, при запуске скрипта Квик чо-то там компилирует - ну и пусть себе компилирует, а я скармливаю ему чистейший Lua как интерпретатору. Всё прекрасно работает! Сейчас я пишу совсем уж сумасшедший скрипт, уже не с трёхмерными, а с четырёхмерными массивами, с разветвлённым диалогом, и я уже совершенно точно знаю, что и он будет прекрасно работать - я просто не вижу, откуда могут появиться проблемы. Вернее, я пока пишу описание, то бишь набросок ТЗ, и пишу уже не первую неделю - задача АЛГОРИТМИЧЕСКИ сложная, а вот ТЕХНИЧЕСКИЕ вопросы решены уже сейчас. Ну, может, вылезет количество функций и/или объём кода за тридцатник - и чего? А может даже и не вылезет. Нафига вам это надо - не понимаю...

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

1. Мне хотелось бы получать с сервера свечи (от 15-минутных и выше), при этом меня интересуют только последние две свечи по каждому таймфрейму, можно даже без коллбеков - только доступ к этим данным.

2. Я не умею программно прочесть состояние своего портфеля (та табличка, которая зелёненьким цвет текста выводит). Портфель я, ессно, веду у себя, но время от времени случаются сбои и рассогласование содержимого портфеля с точки зрения брокера и самого скрипта. Примерно раз в неделю я это дело проверяю (вручную) и убираю нестыковки. А хотелось бы делать это программно, примерно раз в полчаса. Никто не знает, как это сделать?

Опять цитата не моя, а Владимира, Извиняюсь перед собой

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