TGB (Все сообщения пользователя)

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

  Долгое молчание: знак согласия с тем что я написал (дважды)?

  При этом, наверное, надо учесть комментарий s_mike@rambler.ru: https://forum.quik.ru/messages/forum10/message65184/topic7529/#message65184

Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить.
 Пусть разработчик QUIK объяснит, в чем я ошибаюсь.

  Вы, все-таки, покажите разработчикам это:
 И дополнительно:

Павел Bosco, видно, что вы хотите разобраться в том, как функционирует QLua. Но я не вижу вашей реакции на мой комментарий:
Что я не понял в вашей схеме обработки клиентских потоков?  Какие у вас есть возражения против предлагаемых мной изменений вашей схемы обработки клиентских потоков?

  Мне жаль, что Anton перестал с какого-то времени выкладывать свои комментарии. Были ситуации когда мы с ним жестко дискутировали и, наверное, я его иногда обижал. Но я всегда считал. что он много делал полезного для улучшение QUIK и для его пользователей.

 Из того, что написано, можно понять, что ваши клиентские потоки запущенные на С++ кодах используют (под синхронизацией) общий lua_State, выполняя фрагменты Lua-кода. Тем самым эти потоки вмешиваются в существующую схему работы QLua, предполагающую использование QLua-кода только в потоке main и в основном потоке обработки колбеков. Без кода не понять что у вас делается, но вариант близкий к тому что у вас есть, но минимизирующий вмешательство в схему работы QLua мог бы быть следующим (опять гипотеза ). Между потоком main  и клиентскими потоками создаются (для каждого), очередь на прием и очередь на передачу. Взаимодействие потока main и клиентских потоков происходит через такие очереди (синхронизируемые). Поток main обслуживает клиентские потоки, взаимодействуя с QUIK. При этом обеспечиваются условия для параллелизма работы с клиентами и нет вмешательства клиентских потоков в схему работы QLua.

1.    Вы забыли про вылеты и отвисания потому, что усилиями разработчика QUIK и его пользователями было вычищено много глюков (в том числе и ошибок снхронизации). Иначе вылетали бы и отвисали до сих пор.
   Я хорошо знаю как строить устойчиво работающие программные системы, функционирующие в неустойчивых средах (в том числе аппаратных), но когда вижу "корявую" среду, которую можно улучшить, то почему бы это не делать?

2.    У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу   , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.

Уточнение: ответ дан относительно синхронизации при многопоточном использовании Lua.  Чем отличаются замыкания от обычных функций можно прочесть в интернете.

1.   Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато   ), мог ее исправить.  Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.
2. Вы. похоже, не поняли, что у разработчика QUIK не принято признавать свои ошибки (если они это как-то могут скрыть) и благодарить пользователей за найденные ими баги.
3.   Да.

 1. Категорические заявления высказывают обычно дилетанты.

 2. Вы пропустили в первом же комментарии аж восемь пунктов совершенно конкретного кода на C++ демонстрирующего как правильно модифицировать исходники Lua для многопоточного использования.  

 3. Вы, похоже (заметьте   , не утверждаю что точно), не поняли, что после моего комментария разработчики QUIK исправили глобальную ошибки синхронизации в QLua и, что характерно   , сразу после этого сменили номер версии QUIK c 8..  на 9...

 4. Давать советы не видя вашего кода и не имея на это время я не способен.

  Почитайте комментарии начиная с https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696

 Этот код  заготовка для использования в нескольких потоках и ничего не делает в однопоточном Lua. Qlua многопоточный из-за выбранной ARQA архитектуры обработки колбеков в отдельном "основном" потоке. Поэтому разработчик QLua заменяет эту заготовку на свои функции синхронизации доступа к коду Lua из нескольких потоков.
 При том, что в запущенном на выполнение скрипте пользователя существует поток main, коды колбеков этого скрипта выполняются в отдельном "основном" потоке. Но все участки кода Lua (за исключением кодов C-функций Lua) используются в режиме разделения, то есть под синхронизацией, при которой только один может исполнять такой код. Таким образом в QLua параллелизм может возникать (если так сложится) только на кодах C-функций Lua (хоть в main, хоть в колбеках).

 В выложенном фрагменте вашего скрипта этого нет.

Все-таки:
  Вопрос задан две недели назад.
  Выложен код демонстрирующий ситуацию.
  В ветке по ссылки https://forum.quik.ru/messages/forum10/message64619/topic7524/#message64619 мучается пользователь.

 Где ответ поддержки?

  Это вопрос к поддержке.
  Что это за ноу-хау? Нельзя ли обойтись без повтора?

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

2.   QUIK 9.7  Qlua 5.4
Индикатор:

Зачем двойная последовательность вызов функции OnCalculate(index)?:
1) index:  1, 2, 3  ….
2) index:  1, 2, 3  ….
И это, похоже, происходит в любых индикаторах.
Добавляйте в любой график, меняете, например, толщину линии и убеждайтесь.

 Это хорошее решение, если при возникновение nil не возникает других последствий и не нарушается последующее функционирование скрипта.

  Например, в выражении:    i = 6 + '100'   ---  (результат число 106)  будет вызвана прежняя функция tonumber.
  -----
  Существующая схема встраивания Lua в QUIK давно (я это наблюдаю с мая 2020г., а началось гораздо раньше) создает много проблем пользователям и разработчикам QLua. Само по себе, использование Lua это, с учетом IT-квалификации большинства пользователей QUIK, хорошее решение, но идея, запуска колбеков в скриптах пользователя в отдельном потоке, плохая. В этой схеме параллелизма выполнения в скрипте пользователя, при использовании только Lua, все равно нет, но есть почти все сложные проблемы многопоточного программирования, создающие нестабильность работы скриптов, даже если пользователь об этом не знает.  Кому это надо?
  В своем комментарии https://forum.quik.ru/messages/forum10/message64087/topic5823/#message64087
в п.3 я написал, как надо бы встраивать Lua в QUIK с тем, чтобы проблем многопоточности скриптов не было. Это, конечно, не отменяет проблем интерфеса скриптов с QUIK.

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

 -----
Это я проверил 15 минут назад.  Почему у вас не работает непонятно.

Если ваш код Имя_dll.dll оформлен следующим образом (Имя_dll и Имя_пакета_dll это идинтификаторы в латинской кодировке):


А вызов в QLua:


То ваша функция forLua_xx_test  работает в 5.4 в QUIK 9.5.0.42

 1) вы так и не научились выделять фрагменты текста?
 2) объясняю:  мусорщик Lua не является потокобезопасным, и при его запуске на любом lua_State, он может обрабатывать и все остальные lua_State запущенного скрипта. Таким образом оба потока могут писать в одну и туже область памяти.
-----------------------------------
    Читайте:

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

      Этот комментарий пишу, в основном,  для разработчика 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.

Если бы вы это не написали:
 то мне комментировать было бы нечего.
 А так у меня есть предложение как ускорить то, что у вас уже есть.
    Не надо обрабатывать OnTrade. Четвертьсекундный обработчик - ничего не ищет, а просто забирает только вновь появившиеся заявки из таблицы orders а далее как у вас описано но без обработки вашего стека.

   Интересно где этот порядок по скорости?
   Сначала, по колбеку вы заносите данные колбека в свой стек, а затем, наверное, по какому-то таймеру обрабатываете свой стек. И где в таком случае порядок по скорости?

  Хотите вы это или нет таблица все равно пухнет  

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

Заинтриговали:
  Из того, что вы писали я это не понял. Поэтому, пожалуйста, объясните, чем вам не подходят данные из таблиц orders (Заявки) и trades (Сделки), если вы будете их проверять с некоторой периодичностью. В этих таблицах хранятся не какие-то «прерывания», а  выполненные биржей операции (выставленные заявки и выполненные сделки).  Или вам интересно «кувыркаться» с «сырыми» «прерываниями - колбеками», которые то приходят, то не приходят?

 А что же жалуетесь на нестабильность   ?

1.
  Зачем вы заводите новый элемент стека, когда можно было сделать так:

Вы любите писать длинные и неэффективные программы   ?
-----
 Вместо непонятных числовых индексов можно бы было использовать более содержательные текстовые ключи, например: «Тикер», «История сделок» и т.д. Читабельность вашей программы улучшилась бы, а ее эффективность практически не изменилась. Если насчет эффективности у вас есть сомнения,  то проведите эксперименты.
----
 Зачем вы вообще «обрабатываете» OnTrade, когда можно бы было периодически (по таймеру) просматривать таблицы  orders (Заявки) и trades (Сделки), в которых отображается готовые состояния по выполнению ващих транзакций ?
--------------------------------------
2. Зачем вы наезжаете на swerg?
 Он действительно сообщил существенную информацию (мне, например, она была неизвестна) и за это ему спасибо.

    Строка:  ProtectNT((lua_unlock(L), lua_lock(L)));  ошибочна (выяснилось при длительном, недельном тестировании) и ее  следует заменить
    на строку:  savestate(L, ci), lua_unlock(L), lua_lock(L), updatetrap(ci);

  Длинный цикл на «чистом» Lua - это сленг данной ветки, обозначающий долго выполняющийся фрагмент скрипта, в котором нет вызовов C-функций. Например, sleep  это С-функция. С -функциями являются функции из стандартного пакета Lua и многие функции из подключаемых C-пакетов.
 Простейшим примером длинного  цикла на «чистом»  Lua может быть следующий фрагмент кода:
for   i = 1, 5000000000 do    end  
 Если вы вставите этот цикл в свой скрипт сразу после function   main (), то увидите, что пока этот цикл исполняется, ваш терминал полностью «подвиснет» и вы не сможете  даже остановить свой скрипт.
 Приведенный пример, конечно, искусственный, но кто запрещает пользователю написать содержательный фрагмент кода без использования C-функций и исполняющийся достаточно долго.
 Такое «подвисание» QUIK, по-хорошему, надо бы устранить, но, с учетом того что такие ситуации, наверное, редкие, а их устранение – правка сложной виртуальной машины Lua разработчиком QUIK,  то я все больше склоняюсь к тому, что это тот случай, когда можно оставить это как есть.
--------------
   Вы точно отметил: nikolz досих пор не понял, что у меня ник TGB, а не «пользователь».

  Где вы увидели мой код с длинным циклом?
  Вы филосов   ? И готовы комментировать критически все, что угодно, не разбираясь в комментируемом лишь бы накропать свой очередной безумный текст?  Вы, что, до сих не поняли, что в комментируемых вами моих последних сообщениях данной ветки я выступаю не как пользователь, лично со своей проблемой, а обращаю внимание на общую, системную ошибку текущей реализации QUIK?

Код приведенный в моем сообщении 174: https://forum.quik.ru/messages/forum10/message63195/topic6356/#message63195
был проверен мною давно для Lua 5.3.5.

  Для Lua 5.4.1 аналогичный код (но есть отличие), проверенный мною недавно и устраняющий блокировку потоков в QUIK выполнением  длинного цикла пользовательской программы на «чистом» Lua, следующий:
1. В файле   lstate.h  после строки:  volatile l_signalT hookmask;
    добавить: int Счетчик_для_переключения_State;
2. В файле   lstate.с  после строки:  L->errfunc = 0;
   добавить:  L->Счетчик_для_переключения_State = 0;
3. В файле   lstate.с:
    -  после строки:  L1->ci = ci;
   добавить:  L1->Счетчик_для_переключения_State = 0;
    -  после строки:   L->oldpc = 0;
добавить: L->Счетчик_для_переключения_State = 0;
4. В файле   lvm.с  после строки:  StkId ra;  /* instruction's A register */
  добавить:  
   int const Период_переключения_State = 1000;
   if (++L->Счетчик_для_переключения_State > Период_переключения_State) {
       L->Счетчик_для_переключения_State = 0;
       //  ! Имитация вызова "пустой" C-функции  --
       ProtectNT((lua_unlock(L), lua_lock(L)));
   }

 Согласен   .  Наверное, закрывающая тему данной ветки.

  Здесь:  https://www.lua.org/ftp/

  И все таки, похоже,  разработчик реагирует на наши бурные обсуждения.
  Я увидел что в QUIK 9.5.0.42 при обработке колбеков мусорщик не останавливается.

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

  Ну, если вам этот пример не  нравится, то ждите дальше.

  Согласен.

 Читайте:

  Дата центр вам не поможет. Вам надо арендовать для вашего QUIK специальный сервер на бирже с прямыми каналами доступа к торгам.
  Но и это вам не поможет при использовании стандартного рабочего места QUIK, так как API взаимодействия QLua с QUIK выполняется в среде Lua, в которой автоматическое управление памятью, и в произвольные моменты времени может запускаться сборка мусора. Сборка мусора может вносить заметные задержки (не исключено миллисекундные) при взаимодействии вашей программы с QUIK. Вы, конечно, можете отключить сборку мусора, но тогда флаг вам в руки . Попробуйте.
----------
  Вообще, надо заниматься тем, о чем есть хоть какое-то понятие.  HFT роботы не "манна небесная" и о проблемах их использования (как технических так и алгоритмических) достаточно информации в интернете.

 Добавлю:
1) Я уже тогда написал, что вариант предлагаемого решения проверен мною на моем стенде имитации QLua (исключая его API).
2) Последний случай бурного обсуждения системной ошибки QLua, устраняемой моим предложением https://forum.quik.ru/forum10/topic7303/ . Причем этот случай далеко не первый.

 Я написал свое предложение не про вас, не для вас и даже не для, конкретно, себя. Это про системную ошибку в QLua.
 Ну, вы фантазер.  HFT в QUIK   ? Это диагноз.

Мое предложение от  22.04.2021 15:59:54
https://forum.quik.ru/messages/forum10/message55019/topic6356/#message55019
Прошел год.
-----------------
 Напомню описание ситуации и вариант ее устранения.
---
 Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова дру-гих C-функций.
Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов)  являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов.  При этом зависает рабочее место QUIK. Это системная ошибка QLua.
----
  Есть простой вариант реализации пожелания (далее список изменений, реализующих этот вариант в тексте исходников QLua ):
1. В файле   lstate.h  после строки:  lu_byte allowhook;
добавить: int Счетчик_для_переключения_State;
2. В файле   lstate.с  после строки:  L->errfunc = 0;
добавить:  L->Счетчик_для_переключения_State = 0;
3. В файле   lstate.с  после строки:  L1->stacksize = BASIC_STACK_SIZE;
добавить:  L1->Счетчик_для_переключения_State = 0;
4. В файле   lvm.с  после строки:  StkId ra;
добавить:  
if (++L->Счетчик_для_переключения_State > 1000) {   //  1000  надо задать кон-стантой  
 L->Счетчик_для_переключения_State = 0;
 lua_unlock(L); lua_lock(L);
}
-----------------------
В чем проблема реализации этого пожелания?

 Опять адрес форума перепутали ?

Описка. Читать: (а не всех переменных)