Если бы я был архитектором QUIK

Страницы: 1
RSS
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
В Новосибирске, когда то была хорошая школа IT-шников. И что-то, наверное, от нее осталось. Я надеюсь, что архитектором QUIK в текущий момент является один из выпускников этой школы.
   В QUIK все равно будут вноситься изменения (чтобы оставаться «наплаву»). И мне видится, что улучшить QUIK, помимо исправления существующих, неизбежных ошибок, можно внеся в него следующие изменения/дополнения:
1) В текущей версии в одном основном потоке обслуживаются:
- запуск всех Lua-скриптов пользователя;
- запуск коллбеков всех Lua-скриптов пользователя;
-- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
-- обработка всех индикаторов пользователя.
 Притом, что в текущий момент у подавляющего количества ПК много ядер ЦП, написанное выше явный перебор. Мне, представляется, что нет проблем перечисленное выше обрабатывать в отдельных потоках. Иначе, это ограничение пользователя в использовании возможностей его ПК.
2) Интерфейс  взаимодействия QUIK c Lua-скриптом пользователя, реализованный в виде коллбекков, предполагает многопоточный режим использования Lua,. порождающий неприятные проблемы параллельного программирования (для решения которых сами же разработчики предлагают использовать потокобезопасную очередь между коллбеками и потоком main). Мне представляется, что имеет смысл вместо коллбеков использовать активную очередь событий, При этом не требуется использовать Lua в многопоточном, редко используемом и не очень стабильном режиме. При этом не будет проблем с подключением новых версий Lua. Более того, скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования  Lua.
3) В QUIK реализована функциональность просмотра графика котировок бумаг QUIK. Но отсутствует возможность просмотра котировок бумаг, сохраненных во внешних файлах. С учетом существующей функциональности QUIK, как мне представляется, реализация этой возможности не потребует больших усилий.
 
1) - ошибочное утверждение.
------------------
Вот доказательства:
-  запускаем QUIK и смотрим сколько потоков используется без подключения к серверу:

При запуске QUIK создает 5 потоков. (это уже больше чем число ядер)
---------------------------------
- запускаем скрипт


Потоков уже 8.
----------------------------------
-- Запускаем еще один скрипт


Потоков уже 9
-----------------------------
-- Запускаем третий скрипт

Потоков уже 10.
=====================
2) - Разработчики дали решение этой проблемы. Оно прекрасно работает.
Так как QUIK - это бесплатное приложение, то дареному в... не заглядывают.
сделать что-то еще - это их право, но не обязанность.
==================
3) - с этим согласен.
Хотя бы просто открыли формат файлов dat.
Остальное я бы написал и выложил в свободный доступ.
-----------------  
Даже макрософт выкладывает форматы свои файлов.
 
1.
 
Цитата
nikolz написал:
Потоков уже 8.
  Где вы у меня прочитали, что все запущенные пользовательские скрипты работают в одном потоке?
У меня написано:
Цитата
TGB написал:
В текущей версии в одном основном потоке обслуживаются:
- запуск всех Lua-скриптов пользователя;
- запуск коллбеков всех Lua-скриптов пользователя;
- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
- обработка всех индикаторов пользователя.
Вам до сих пор неизвестно, что в QUIK существует служебный, так называемый основной единственный поток, выполняющий то, что перечислено мною выше?
Когда же вы научитесь читать чужие сообщения?

2.
Цитата
nikolz написал:
Разработчики дали решение этой проблемы. Оно прекрасно работает. Так как QUIK - это бесплатное приложение, то дареному в... не заглядывают. сделать что-то еще - это их право, но не обязанность.
 Вы, похоже, очень наивны и полагаете, что разработчики работают за бесплатно? Можно, наверное как то сообразить, что часть комиссии, уплачиваемая брокерам пользователями, идет на зарплату разработчикам, а также в доход акционерам ARQA.
 
Цитата
TGB написал:
2) Интерфейс  взаимодействия QUIK c Lua-скриптом пользователя, реализованный в виде коллбекков, предполагает многопоточный режим использования Lua,. порождающий неприятные проблемы параллельного программирования (для решения которых сами же разработчики предлагают использовать потокобезопасную очередь между коллбеками и потоком main). Мне представляется, что имеет смысл вместо коллбеков использовать активную очередь событий, При этом не требуется использовать Lua в многопоточном, редко используемом и не очень стабильном режиме. При этом не будет проблем с подключением новых версий Lua. Более того, скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования  Lua.


TGB,  Не люблю высказываться на подобные темы, но ту Вы даже меня удивили. Мир стоит на пороге квантовых вычислений, а Вы предлагаете еще дальше откатиться в средние века. Создать "активную очередь событий" не знаю что Вы под этим понятием имеете ввиду, но очередь предполагает последовательное выполнение (вычисления) кода.  О какой же многопоточности речь идет, все коллбекки исполняются в основном потоке, асинхронность создается в момент срабатывания функций обратного вызова, т.е. вызвали что то сделали и снова последовательное выполнение. При этом Вы сами пишите отвечая nikolz,  "... в QUIK существует служебный, так называемый основной единственный поток, выполняющий то, что перечислено мною выше?", получается что нужно отказаться от отдельного потока main и выполнение main разместить в основном потоке , при этом создав "активную очередь событий".
Цитата
TGB написал:
В Новосибирске, когда то была хорошая школа IT-шников. И что-то, наверное, от нее осталось. Я надеюсь, что архитектором QUIK в текущий момент является один из выпускников этой школы.
Школа как была отличной, так и остается, и дело на мой взгляд не в программистах, а в том как управляется проект (в главном конструкторе). Даже пример этого форума показывает Нельзя отпускать программиста (понапишут такого), без  контроля инженера (следящего за прикладным характером задачи) .
 
Цитата
VPM написал:
получается что нужно отказаться от отдельного потока main и выполнение main разместить в основном потоке , при этом создав "активную очередь событий".
  Я этого не писал.
-------
  Вообще то, не хочу вас, обидеть, но в моем сообщении пункты 1) и 2) написаны не для либеза. Думаю, что разработчикам QUIK понятно о чем я пишу в этих пунктах.
 
Цитата
TGB написал:
1) В текущей версии в одном основном потоке обслуживаются:- запуск всех Lua-скриптов пользователя;- запуск коллбеков всех Lua-скриптов пользователя;-- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);-- обработка всех индикаторов пользователя.
Зачем столько фантазии и эмоций.
Сложно понять что думал человек, написавший три предложения.
Давайте разберем то, что Вы написали и то, как я это понял.
------------------  
Вот Ваши предложения:
1) В текущей версии в одном основном потоке обслуживаются:
- запуск всех Lua-скриптов пользователя;
- запуск коллбеков всех Lua-скриптов пользователя;
-- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
-- обработка всех индикаторов пользователя.
----------------------------
Разбираем:
Вам не нравиться ,что  в основном потоке терминала выполняется:
запуск всех Lua Скриптов пользователя.
--------------
И что в этом плохого?
Мое мнение - это выполняется однократно и на дальнейшую работу скриптов не влияет. поэтому никакой проблемы в этом нет.
Докажите, что это не так.
----------------------
- запуск коллбеков всех Lua-скриптов пользователя;
Мое мнение:
Колбеки не запускаются, а вызываются.
Вызываются они в основном потоке, потому что иначе они не могут вызываться. Они и есть реакция на события в этом потоке.
Вы знаете иной механизм вызова колбеков?
Расскажите .
--------------------
-- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
Вообще непонятно. Что за "обработка" ?
В каком основном потоке ?
-------------------
-- обработка всех индикаторов пользователя.
В каком основном потоке?
Где это Вы прочитали ?
===================  
Поэтому Ваши высказывания ошибочны.
если Вы не согласны, то докажите,а не обвиняйте, что другие не умеют читать Ваши мысли.
 
1.
Цитата
nikolz написал:
Вам не нравиться ,что  в основном потоке терминала выполняется:запуск всех Lua Скриптов пользователя.--------------И что в этом плохого?
  Это мелочь, но при условии, что пакеты в скриптах подключаются в потоке main. Иначе одновременный запуск нескольких скриптов выполняется долго (из-за того, что это это выполняется в одном потоке).

2.
Цитата
nikolz написал:
Мое мнение:Колбеки не запускаются, а вызываются.
 Пусть для вас вызывается, а для меня запускается  :smile: . Кому непонятно, что это одно и тоже?

3. По остальной части вашего комментария:
   Пользовательские индикаторы в графиках обрабатываются в основном (единственном) потоке. Это медицинский факт. Если вы не знаете как это проверить экспериментально, то я вам расскажу как это сделать. дополнительно, в основном (единственном) потоке запускаются коллбеки всех скриптов пользователя, а также вызываются коллбеки всех таблиц QUIK, созданных пользователем. Наверное, понятно и ежу, что в текущий момент в одном потоке все это будет выполняться последовательно. Это значит, что на архитектурном уровне QUIK в  текущий момент существует зависимость по выполнению для его различных функциональностей, что является некоторым дефектом. Кому это непонятно?

3.
Цитата
TGB написал:
Вы, похоже, очень наивны и полагаете, что разработчики работают за бесплатно? Можно, наверное как то сообразить, что часть комиссии, уплачиваемая брокерам пользователями, идет на зарплату разработчикам, а также в доход акционерам ARQA.
 Где возражения?
 
Пропустил:
Цитата
nikolz написал:
В каком основном потоке ?
  Есть такой документ разработчика QUIK: "Использование Lua в Рабочем месте QUIK". Найдите в интернете и почитайте.
 
Цитата
nikolz написал:
- запуск коллбеков всех Lua-скриптов пользователя;Мое мнение:Колбеки не запускаются, а вызываются. Вызываются они в основном потоке, потому что иначе они не могут вызываться. Они и есть реакция на события в этом потоке.Вы знаете иной механизм вызова колбеков? Расскажите .
Как я понимаю человек предлагает вызывать колбеки в потоке Lua-скрипта.
 
Цитата
Constantin написал:
Как я понимаю человек предлагает вызывать колбеки в потоке Lua-скрипта.
  Один из возможных вариантов предлагаемой обработки событий Qlua:
  1)  вместо регистрации функций обратного вызова, регистрация соответствующих потокобезопасных очередей событий (возможно, с теми же именами);  я бы сделал эти очереди (можно, в принципе, обойтись и одной) циклическими, с указанием их длины при регистрации, но не более некоторого значения;
  2)  вместо sleep, служебная функция с тем же именем ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);
  3)    добавление функции чтения очередей событий (их параметров).
  Эта схема реализует рекомендованную ARQA обработку параметров событий в main (смотрите "Использование Lua в Рабочем месте QUIK"), с тем, чтобы не было проблем синхронизации в скриптах.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться конфигурирования Lua для многопоточного использования (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua  в QUIK станет в описанной выше схеме рутинной задачей.
 
Мне интересна реакции разработчика QUIK, в лице поддержки, на те пункты, которые мною предлагаются.
--------
 На всякий случай, по пункту 2:
Есть вариант его реализации таким образом. чтобы сохранить существующий интерфейс QLua c QUIK, с тем, чтобы пользователям не надо было изменять существующие скрипты. Это вызов функций обработки коллбеков в видоизмененной sleep с параметрами в нужном формате, считанными из предлагаемых очередей (очереди).
 
Цитата
TGB написал:
Цитата
Constantin написал:
Как я понимаю человек предлагает вызывать колбеки в потоке Lua-скрипта.
   Один из возможных вариантов предлагаемой обработки событий Qlua:
  1)  вместо регистрации функций обратного вызова, регистрация соответствующих потокобезопасных очередей событий (возможно, с теми же именами);  я бы сделал эти очереди (можно, в принципе, обойтись и одной) циклическими, с указанием их длины при регистрации, но не более некоторого значения;
  2)  вместо sleep, служебная функция с тем же именем ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);
  3)    добавление функции чтения очередей событий (их параметров).
  Эта схема реализует рекомендованную ARQA обработку параметров событий в main (смотрите "Использование Lua в Рабочем месте QUIK"), с тем, чтобы не было проблем синхронизации в скриптах.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться конфигурирования Lua для многопоточного использования (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua  в QUIK станет в описанной выше схеме рутинной задачей.
Это делается очень просто.
----------------------
Применяю это с момента появления VMLua в КВИКЕ.
---------------------
Возьмите готовую библиотеку https://quik2dde.ru/viewtopic.php?id=78
------------------
и используйте всего две функции
CreateEvent и  WaitForSingleObject
-------------------
Как реализовать очередь есть в документации QLUA  
 
Цитата
Constantin написал:
Цитата
nikolz написал:
- запуск коллбеков всех Lua-скриптов пользователя;Мое мнение:Колбеки не запускаются, а вызываются. Вызываются они в основном потоке, потому что иначе они не могут вызываться. Они и есть реакция на события в этом потоке.Вы знаете иной механизм вызова колбеков? Расскажите .
Как я понимаю человек предлагает вызывать колбеки в потоке Lua-скрипта.
Мечтать не вредно.
Пусть сначала сделает и докажет,  что это лучше.
--------------
Существующее решение работает быстро и даже раньше, чем данные попадают в таблицы терминала.
 
 
TGB,
Sleep - это функция, которая останавливает поток и возвращает управление OC.
Что Вы будете модифицировать в ней?
 
1.
Цитата
nikolz написал:
Это делается очень просто. ----------------------Применяю это с момента появления VMLua в КВИКЕ.---------------------Возьмите готовую библиотеку  https://quik2dde.ru/viewtopic.php?id=78 ------------------и используйте всего две функцииCreateEvent и  WaitForSingleObject-------------------Как реализовать очередь есть в документации QLUA  
  Опять вы не поняли. То о чем вы пишите, я у себя реализовал давно, как только начал разбираться с QUIK.
  Сутью 2-го пункта является;
Цитата
TGB написал:
в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться конфигурирования Lua для многопоточного использования (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua  в QUIK станет в описанной выше схеме рутинной задачей.

2.
Цитата
nikolz написал:
TGB ,
Sleep - это функция, которая останавливает поток и возвращает управление OC.
Что Вы будете модифицировать в ней?
Опять, та же фигня :smile: .  
Я пишу про sleep (это функция QLua):
Цитата
TGB написал:
Это вызов функций обработки коллбеков в видоизмененной sleep с параметрами в нужном формате, считанными из предлагаемых очередей (очереди).
а вы про системную Sleep. Вы, что, не понимаете разницы?

3.
Цитата
TGB написал:
Вы, похоже, очень наивны и полагаете, что разработчики работают за бесплатно? Можно, наверное как то сообразить, что часть комиссии, уплачиваемая брокерам пользователями, идет на зарплату разработчикам, а также в доход акционерам ARQA.
 Где возражения?
 
Цитата
TGB написал:
2.  
Цитата
nikolz написал:
 TGB  ,
Sleep - это функция, которая останавливает поток и возвращает управление OC.
Что Вы будете модифицировать в ней?
 Опять, та же фигня :: .  
Я пишу про sleep (это функция QLua):
Цитата
Фигня это у Вас.
sleep в QLua - это обертка для Sleep OC.
Поэтому Ваше рассуждение про "модификацию" - это пустая фраза.
 
TGB,
Про колебки Вы пишите фигню.
Колбеки не запускаются, а вызываются.
------------------------
Никто не мешает Вам запустить в колбеке новый поток.
--------------
Я это использую уже давно.
Об это писал у же на форуме.
 
Вы тоже не читаете внимательно чужие предложения.
Я на форуме не только предлагал, но и показывал как это работает у меня.
-------------------
Например, я выполнение различных алгоритмов обработки событий реализую не только на Lua, но и на Luajit ( что более чем на порядок быстрее)
на Terra, на Python, на julia.  
 
вот тут можете посмотреть варианты как делать очередь.
И результаты тестов различных вариантов.
https://forum.quik.ru/forum17/topic8426/
---------------
С интересом посмотрю Ваши результаты решений.
Может обсудить конкретные решение, что будет полагаю интересно начинающим.
 
1.
Цитата
nikolz написал:
Я на форуме не только предлагал, но и показывал как это работает у меня.
   Вы опять не поняли.  Я эту ветку создал не для того чтобы обсуждать свои или чужие решения. До сих пор я понимал и решал свои проблемы и при этом пользовался интернетом.
  Если вы читали мой первый комментарий, то в нем написано как можно улучшить QUIK.
2.
Цитата
nikolz написал:
И результаты тестов различных вариантов. https://forum.quik.ru/forum17/topic8426/
 Несмотря на написанное мною в первом пункте, посмотрел и впечатлился:
.
Цитата
nikolz написал:
Смотрим первую картинку.
Нижнее 3 окно в ней - это график прибыль/убыток за 2023 год.
линия зеленая на оси справа показывает положительные 220% -это профит лонг.
линия синяя на оси справа показывает положительные 150% - это профит short
линия белая на оси справа показывает положительные 370% - это профит long+short.
 Сдаюсь :smile: . Таких годовых процентов у меня не было.
Вам мой совет возьмите кредит, ну хотя бы 1000000 руб., ну хотя бы под 20% годовых на 3 года.
Вам светит за три года приблизительно следующая сумма: 1000000 * 3,7 * 3,7 * 3,7 - 1000000 - 3*1000000*0,2 = 49000000 руб.
А может вы уже и сейчас миллиордер :smile: ?
 
Если скрипту давать работать с 10% от депозита, то получится 37% годовых грязными, или 32% чистыми. Если вместо воды пить шампанское, получается не так уж и много...

Когда-то давно в телеграм канале один старый трейдер советовал брать и держать акции сберика, когда одна стоила 132 р., потом когда 137 р., 142 р., т.к. идёт долгострочный тренд с прицелом на ист. максимум. Если бы я послушал его, то сейчас без всяких "ботов" и "стратегий" имел бы 100% годовых чистыми...

Подозреваю, что если бы я подписался на платный канал к.э.н. с птичьей фамилией из Владивостока, который следит за фондовым рынком, то было бы примерно то же...
 
Цитата
TGB написал:
Вам светит за три года приблизительно следующая сумма: 1000000 * 3,7 * 3,7 * 3,7 - 1000000 - 3*1000000*0,2 = 49000000 руб.
  В приблизительных вычислениях ошибка, но возражения не дождался.
Точно: 1000000 * 4,7 * 4,7 * 4,7 - 1000000 - 3*1000000*0,2 = 102223000 руб. до уплаты налога.
 
Этот комментарий, сугубо, для поддержки QUIK.
---
 Как результат  *  в данной ветке, возникло дополнительное предложение:
 4) На форумах ARQA для комментирующих пользователей ввести месячный лимит трафика, после которого не будет возможность вводить комментарии.
     Значением этого лимита могло быть: <Годовой трафик nikolz> / 12 / 10. Но, конечно, насчет значения лимита, решать ARQA.
     Наличие такого лимита, обеспечило бы:
      - экономию дискового пространства баз форумов;
      - автоматическое модерирование форумов за счет принуждения думать о краткости и четкости текстов, пишущих комментаторами;
      - удобство для читающих комментарии, в которых будет меньше флуда.
 
Протокол начала утренней сессии (типичный случай):
KW 25.09.25 03:15:00:724 #578:TRADER Ждет возобновления связи
KW 25.09.25 07:00:14:716 --- OnCleanUp (прилетел) -----------------
KW 25.09.25 07:00:38:873 #590:TRADER Соединение с сервером восстановлено, ждет 10 сек. подгрузки данных
KW 25.09.25 07:00:48:873 #608:TRADER Возобновил работу
--- Задержка возможности что-то делать 48 сек.
----
В этой ветке я написал о том, что существующая архитектуре QUIK порождает проблемы.
И вот практическое подтверждение этому. Мне потребовалось что-то сделать в начале утренней сессии.
Ноут 8 ядер 4 Ггц, SSD-скорость последовательного чтения 3 Гб.
В пересчет на флагман советской индустрии БЭСМ-6 (~1000000 операций в сек.) задержка (48 * 1000 сек.) более 13 часов с начала утренней сессии :smile: .
1. Что делает QUIK 13 часов?
-----
2. Код в любом месте любого скрипта:
   for i = 1, 4000000000 do   end
 "обездвиживает" QUIK на 10 секунд (длительность зависит от производительности ПК), он не отвечает. Я понимаю, что такой код писать нехорошо, но как написан QUIK, что зацикливание в пользовательском скрипте полностью его "обездвиживает"?
3. При переключении индикаторов, QUIK на какое-то время впадает в "ступпор". Можно ли сделать так, чтобы этого не было? Или это нерешаемая задача?
4. Перезапуск QUIKа выполняется долго (в пересчете на БЭСМ-6 ~13 часов :)). Как удалось этого добиться :smile: ?
 
На вопросы в общей постановке, ответа я не вижу.
 1. Отвечать не отвечают, но реагируют  :smile: .
  Протокол начала утренней сессии 29.09.25:
KW 29.09.25 06:50:10:519 --- OnCleanUp (прилетел) -----------------
KW 29.09.25 06:50:32:746 #590:TRADER_lib Соединение с сервером восстановлено, ждет 10 сек. подгрузки данных
KW 29.09.25 06:50:42:754 #608:TRADER_lib Возобновил работу

 2. Проблема с длительностью запуска QUIK пока осталась.
    Для быстрого восстановления функционирования программ используются контрольные точки. Это значения переменных программ, возникшие при их выполнении и сохраненные в энергонезависимой памяти для возможности быстрого продолжения их работы, начиная с сохраненного состояния, после их перезапуска по любой причине (сбой аппаратуры, программная ошибка, и т.д.).
    Например:
       1) Windows (программный монстр), используя контрольную точку, просыпается из режима сна за ~1сек.
       2) Chrome (большая программа) c 50 вкладками открывается через ~2 сек.
       3) В моих многоскриптовых роботах, со скриптами (в количестве:3-6), взаимодействующими между собой, есть режим, в котором
           после начала запуска/перезапуска, они готовы к продолжению прерванной работы менее чем через 15 млс.
----
     На сервере есть контрольные точки терминалов (QUIKов) для быстрого продолжения работы с ними после любого его перезапуска?
     В QUIKе есть контрольная точка для быстрого продолжения работы с сервером после любого перезапуска QUIK?
 
Цитата
TGB написал:
но реагируют  
 Из текста фрагмента протокола видно, но, наверное, надо пояснить:
     мною в меню "Система > Соединения.. > Восстанавливать связь автоматически"   было указано начало c 6.50.
 
Добрый день.

Просьба подсказать, претензия в том, что после подключения к серверу по настройке Восстанавливать связь автоматически QUIK долго получает данные? Если да, то на какие именно данные ориентируетесь?
Проблема исключительно только утром?
 
Цитата
Egor Zaytsev написал:
Просьба подсказать, претензия в том, что после подключения к серверу по настройке Восстанавливать связь автоматически QUIK долго получает данные? Если да, то на какие именно данные ориентируетесь? Проблема исключительно только утром?

 Ситуации:
   1) При проверке многократной (> 8 раз) остановки/запуска скрипта, в котором используется сторонний графический пакет IUP, QUIK (версия 12.6.1.2, Lua 5.4), после разного количества экспериментов, в моменты останова/запуска, падает:    
     Дамп info_dmp_20251007_150748.dmp вышлю почтой. Могу наделать сколько нужно.  
     Причина 0xc0000005 - Потоком была предпринята попытка прочитать или записать данные на виртуальный адрес, к которому он не имеет соответствующего доступа.
      Это происходит только в рабочем экземпляре QUIK. В песочнице с такой же версией этого нет.
      В работе проблем с пакетом IUP не обнаружено (использую давно, но ранее при проверке запуска/перезапуска делал это 3-4 раза.).
      Экспериментально выяснил, что перенос закрытия IUP (iup:Close()) из служебного потока OnStop в пользовательский поток main, ситуацию исправляет. QUIK падать перестает. Но почему iup:Close() "ломает" поток OnStop? Опять что-нибудь с синхронизацией?
      Похоже, это очередная ситуация, подтверждающая то, что мною написано в п. 2) комментария https://forum.quik.ru/messages/forum10/message74919/topic8563/#message74919. В комментарии https://forum.quik.ru/messages/forum10/message74928/topic8563/#message74928  предлагается вариант реализации п. 2).
В комментарии https://forum.quik.ru/messages/forum10/message74960/topic8563/#message74960 есть предложение, как при реализации п. 2), сохранить существующий интерфейс QLua c QUIK.
-------
    При экспериментировании замучился ожидать перезапуски QUIK и об этом следующий пункт.

   2) Задержка при запуске/перезапуске QUIK на моем ноутбуке, с ранее перечисленными характеристиками: ~1 мин. Это много и неоднократно в разные года обсуждалось в различных ветках.
      Мои комментарии трассировки запуска рабочего QUIK выделены символами ##.
Код
KW 08.10.25 16:50:36:220             ## Остановлен QUIK (16:50:36:220)
    --- @  Остановлен по стоп бот D:\0 D\0 TGB\B_Q\Bots\B1  @ ---
                                     ## Через ~ 1 сек. QUIK запущен
 ==================================
KW 08.10.25 16:51:02:693             ## Начало работы скрипта (длительность от начала запуска 26 сек.)
        Begin_Require: 08.10.25 16:51:02:693.  End_Require: 08.10.25 16:51:02:696   ## Загружены все пакеты скрипта (длительность загрузки 3 млс.)
KW 08.10.25 16:51:02:717 ACCOUNT, CLASS_CODES,  CLIENT_CODES, FIRM_ID:              ## Получены реквизиты и скрипт готов продолжать работать
KW 08.10.25 16:51:02:717 #572:TRADER_lib Нет подключения к серверу
KW 08.10.25 16:51:02:717 #575:TRADER_lib С сервера не поступают необходимые данные
KW 08.10.25 16:51:02:717 #578:TRADER_lib Ждет возобновления связи
KW 08.10.25 16:51:25:197 #590:TRADER_lib Соединение с сервером восстановлено, ждет 10 сек. подгрузки данных
KW 08.10.25 16:51:35:201 #608:TRADER_lib Возобновил работу                         ##  (16:51:35:201)  Итого: длительность перезапуска ~ 1 мин.

      Переформулирую два заданные ранее вопросы в один:
   Для взаимодействия сервера с терминалом QUIK существует протокол его быстрого восстановления при разрывах его по любой причине?
      Я не представляю, где проблемы с быстрым перезапуском QUIK с учетом того, что:
   1) в ОС (Windows) многое кэшируется (на моем ноуте 32 Гб. и перезапуск выполняется сразу после падения QUIK);
   2) реализован более менее приличный протокол быстрого восстановления взаимодействия.
Страницы: 1
Читают тему
Наверх