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

Если это беспокоит, то работа с колбеками организован некорректно. Приход колбека должен быть не прерыванием, а добавлением события в очередь. Когда завершите всю работу с инициализацией, то разберете колбеки что пришли, если пришли. А порядок инициализации не испортится, если это сделать не в OnInit. Вы же сами его задаете, вызывая последовательно модули. Хотя и здесь, если вдруг потребуется его изменить, придется переписывать код.

Также, как я уже сказал выше, передача модулей по ссылкам выглядит "коряво".

OrderManager.init({ExecutionLedger = ExecutionLedger, Logger = Logger})

Если бы каждый модуль сам подключал библиотеки через require, то и передавать их не придется. Например, какой-то модуль для своей работы требует библиотеку, которая больше нигде не используется. Почему же модель сам не подключит ее и будет работать с ней. Если он один, то скажете: хорошо, тогда там и подключу его через dofile. А если таких модулей два? В итоге Вы вынуждены подключать их в одном месте и передавать как параметры.

Хотя задача решается элементарно:


Где подключать my_module1, my_module2 и в каком порядке - вопрос второй. Но смысл в том, что каждый модуль несет ответственность за свой контекст.

Здесь не так использование dofile, что и заставляет использовать так. Я не вижу все файлы, то проблема dofile в том, что он каждый раз локализует и исполняет файл. Что кардинально отличается от require. Также dofile работает в глобальном контексте, не позволит подключить один и тот же файл один раз в разных модулях, например, тот же модуль логирования. Вы же из-за такой схемы передаете модули как параметры и будет вынуждены так и гонять контекст туда-обратно. Также если метод  utils.safeParam - это оболочка для getParamEx, то в OnInt не стоит его вызывать, это уже не технологический запрос, а логический к данным.

А сам OnInit в таком виде - не нужен. Я меня также его нет, просто вызываю в начале main свой метод on_init, где выполняю технологические операции при старте скрипта.

А теперь представьте, что у вас запускаемый скрипт не содержит main. Т.е. тот файл, что выбирает в Квик - это скрbпт без main. Единственное, что этот скрипт делает - это подключает библиотеки и устанавливает параметры, имеет свой искатель библиотек (если нужно).

А как же это работает? Просто - подключая какую-то библиотеку через require, выполняется тело библиотеки. И в какой-то есть main.
Т.о. этот запускаемый файл и выполняет роль инициализатора скрипта. Почему - это не в OnInit. Ответ прост - это намного гибче, т.к. пока дойдем до выполнения main уже выполнится много кода, инициализирующую среду исполнения. Причем в зависимости от скрипта, инициализация разная, может быть сложная, в может простая. Каждая подключаемая библиотека тоже что-то свое подключает.

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

Также достаточно просто посмотреть на схему выполнения Lua скрипта в документации, где видно, что сначала выполняется body, а потом OnInit скрипта. Т.е. с точки зрения main они равнозначны  - выполняются до main. А вот у же с точки зрения OnInit отсутствие body - это недостаток, т.к. когда проект состоит из десятков файлов со своей инициализацией, то контроль за процессом запуска только в OnInit - это сложно.

И с таким подходом, OnInit - совсем не обязательная сущность.Возможно я не понял это, но максимум, что можно сделать до main - это прочитать что-то с диска. Ни о каких восстановлении состояния речи не может быть, т.к. восстановление подразумевает и актуализацию после подключения к серверу. Если это просто чтение, то да. Но и это я тоже не делаю в OnInit, т.к. скрипт может не останавливаться и работать сутками без выключения терминала. Это значит, что OnInit вызвался вчера, а сегодня что? Надо же после восстановления связи с сервером и обновления таблиц тоже актуализировать состояние, проверить что случилось, что есть в данных и т.д. И делать это надо при старте каждого дня пока скрипт работает. А работать он может месяцами.

Поэтому OnInit - это технический колбек, просто сигнализирующий, что код исполненный выше в body скрипта при его запуске, не привел к ошибкам. Ничего более. Делается это один раз при запуске. Поэтому там и могут быть только сугубо технические действия именно при запуске скрипта и ничего более.

Ну видимо, т.к. я ушел с срочки давно, то и проблема не коснулась. Хотя меня уже объединяли в один терминал по нескольким брокерским счетам, т.к. у меня их не один у Сбера.
Там осталась фонда и ИИС.

Лучше проще. Я банально перестал совершать сделки на срочной секции у брокера Сбер. С такими комиссиями, спасибо, не надо.

Выведите все записи таблиц futures_client_holding, futures_client_limits, money_limits, depo_limits, account_positions, account_balance

И банально посмотрите на данные. Иногда это проще и быстрее, чем ждать ответ.

На своем.

Ну это, конечно, ошибка если зависает. Если мне нужен простой скрипт для расчета и завершится, то я не ввожу main и любые колбеки. Просто тело скрипта.

Запустил Ваш скрипт у себя, изменив данные и дату limit_kind на сегодняшнюю. Нет проблем. И с вашими данными, очевидно не подходящими, тоже нет проблем.  

При том, что его там нет. Именно это и приводит к "зависанию" терминала.

Опять читаем документацию
И вклинился, и что? Если под этим подразумевается, что в коде вообще не предусмотрено получение вручную данных из таблицы depo_limits, то, конечно, другого варианта как считывать данные в колбеке нет. Но тогда все равно не ясно зачем это делать в служебном колбеке OnInit. Делайте в специализированном OnDepoLimit. Он, если судить по предоставленной событийной модели в документации, все равно вызовется после OnInit. Дайте провести инициализацию скрипта, пусть запустится main. В нем можно считать данные начала. А потом все обрабатывать по приходу OnDepoLimit. Если OnDepoLimit вызовется раньше чем код дойдет до места в main где вызывается getDepoEx, то это ни на что не повлияет, т.к. getDepoEx уже получит актуальные данные.

Это давно известный факт, и я про него написал выше "если убрать sleep, терминал "умрет""

Не совсем. Сначала необходимо узнать есть в таблице записи, запросив размер таблицы. Это все же разные запросы, хоть и тоже метод qlua

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

Не очевидно совсем. Этот колбек вызывается очень часто, и не только при изменении позиции. Более того, в определенные моменты торговой сессии, там могут быть некорректные данные. Т.е. необходимо не просто брать данные, а понимать можно ли их брать в этот момент времени. Также, корректно сделать ручной запрос перед принятием решения, зависящего от данных в таблице depo_limits. Колбек - это хорошо, но я очень много раз видел, как в терминал пришли сделки, а позиция в depo_limits обновляется с существенной задержкой. Или, что тоже часто, есть сделки выхода из позиции, по идее можно установить обратно ордера на открытие позиции, а брокер не дает и пишет что денег нет. Т.е. данные еще не обновились.

Так что можете использовать колбеки, никто не мешает. Но речь же про OnInit, а не все колбеки как таковые.

Так любой синхронный код, на то и синхронный, что пока вызов идет, то дальше код не исполняется. Здесь ничего нового. И опять - я не знаю как выполняются qlua методы, вызываемые из main. Но если читать документацию
можно предположить, что все же вызов методов qlua из main организован без вызова основного потока. Но и не без проблем, т.к. если убрать sleep, терминал "умрет".

Можно и в колбеках, если угодно, но не в OnInit точно. Начальное заполнение можно выполнить и при запуске main, в начале тела функции. Это не будет сильно отличаться по времени от OnInit.

Но, по хорошему, прежде чем выполнять какие-то запросы, необходимо дождаться, что данные есть в терминале. Если скрипт стартует вместе с терминалом, а брокер вызывает OnCleanUp, то пока данные не загрузятся, вызывать getDepoEx не имеет смысла. Поэтому - сначала старт скрипта, потом проверка наличия данных, потом запрос данных. Но точно не в OnInit когда вообще даже подключения к серверу может не быть.

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

Когда проверять позицию - это вопрос субъективный. Можно по колбеку OnDepoLimit, но стоит учитывать, что будут постоянные вызовы не связанные с изменением позиции. Можно по новой сделке. А если требуется смотреть не только позицию, то и по изменению в таблице ордеров, например. Все зависит от задачи.

Здесь вопрос самой концепции. OnInit - это сигнал, что скрипт запускается и прямо сказано, что перед вызовом функции main(). А т.к. это колбек, то и в потоке интерфейса терминала.
Т.е. это некий пограничный момент. Т.к. реализацию работы с потоками мы не знаем, то вполне может происходить некий конфликт - скрипт стартует, формируется доп. поток main. А здесь ему пинок - иди выполни qlua метод. Да, любое зависание основного окна приложения - это ошибка, баг. С этим не поспоришь.

Возможно это и проблема, но, честно говоря, вызов getDepoEx внутри колбека OnInit выглядит странно.  

onTransReply все же не столь показателен, т.к. таблицы транзакций нет.

Т.е. то что я делаю уже лет 20 на Mac. Приложения не закрываются - зачем, система не выключается - зачем?

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

Уж не знаю что изменялось в 12-ой версии, но скрипты стали работать с памятью как это было во времена версии 5.3. Память скрипта скачет на несколько мб и сбрасывается. Это не во всех скриптах, если он небольшой, то такого нет. Но если код большой, то происходят "скачки". После перехода на 5.4 - это ушло, стало стабильно, с небольшими колебаниями в сотни кб. А теперь опять. Приходится ставить достаточно корявый костыль

SearchItems('money_limits', 0, 0, empty_func, "currcode")

И память стоит как влитая, даже на сложных, объемных скриптах.

Пока гарантированность не будет указана в документации, то все это спекуляции. Я, конечно, могу предположить, что если документация банально написана плохо, то многие моменты там не будут указаны.
Но тогда, необходимо хотя бы подтверждение от поддержки.

1: 99 мб
2: 28 мб
3: 60 мб

1-й самый медленный. Но он всегда был таким, даже когда ничего не было открыто.
В 1-ом и 3-ем есть поток данных по опционам.

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

Так что в очередной раз новая версия заставляет заниматься бесполезной деятельностью.

Я не искал специально на форме, это было еще в 7-ой версии терминала. Т.к. после этих случаев я просто изменил подход, то и нет необходимости отслеживать. В данном случае - решение каждый принимает сам.
Данная дискуссия просто обсуждение подходов с учетом официальной информации доступной в документации.

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

Вы в документации видите утверждение о гарантированности доставки, вызова. А если нет, то значит это не ошибка, а особенность. В документации к RabbitMQ гарантируют доставку, а здесь нет.

Банально не был вызван, а в таблице данные корректны. В текущих версиях это очень редко, а ранее было не так и редко.

И когда она решит это вызвать? Когда цена уже пройдет две планки? Т.е. эту фразу я воспринимаю так: ориентируемся на колбек. Если он не пришел, каким-то образом, скорее всего с некой периодичностью читаем данные и сверяем. Т.е. данные подтверждаются с неким интервалом, возможно даже не таким и маленьким. Да, если считать, что колбек с вероятностью 99.99999 приходит, то можно предложить взять такой риск. Но я уже давно понял, что достаточно одного события с 10 сигма, чтобы потом очень сильно пожалеть. Тем более, что если скрипт не только для себя.

Ок. Предположим, что скрипт пишется корректно, и в колбеках только быстрое обновление информации, передача полученной информации в поток main.

Это предположение, а не факт. А также не отвечает на вопрос, что делать с пропусками, если блока чтения данных напрямую не предусмотрено.

Учитывать для чего? Если Вы не выполняете код в колбеке, а, как минимум, транзакции отправлять точно не стоит, то чтобы выполнить какое-то действие вы должны вернуться в mian. А значит эта задержка, какая бы она не была, есть постоянная для алгоритма.

Это просто субъективное соображение.



Ок. Пусть есть колбек для таблицы ордеров. Вы его обработали, что-то сделали с информацией. Можно, конечно, даже провести какие-то расчеты в колбеке, но тогда уже стоит учитывать, что данное решение будет плохо масштабироваться, на, скажем, 100 инструментов в одном скрипте. Рекомендация от разработчиков проста - взяли данные в колбеке и передали в main, и уже там с ней работает. И здесь возникает вопрос: если перед принятием решения необходимо иметь актуальную информацию и это мы делаем в main, то что мешает прямо перед принятием решения посмотреть на данные?

Если же колбек используется просто как светофор, то эту модель я как раз могу понять. У нас есть некий метод получения состояния портфеля или другой информации зависящей от сделок, установленных ордеров и т.д. И чтобы постоянно не опрашивать его, можно колбек использовать как сигнал для обновления. Сами данные все равно будет опрошены в main, но уже не постоянно, а по сигналу.

Еще один пример для колбека OnQuote. Я очень часто вижу как внутри этого колбека читают стакан и разбирают данные. И возникает вопрос - а точно понимают что делают?
Пришел колбек, что данные в стакане изменились. Хорошо. Для чего нам эта информация? Если необходимо фиксировать все изменения в потоке времени, а потом их анализировать, то да, другого выхода нет, необходимо читать и разбирать. А если данные стакана потребуются уже только в main, когда дойдем до некого метода где требуется информация о текущем состоянии, то прямо там и надо его прочитать один раз, если был сигнал от колбека. Т.е. сам колбек - это сигнал, что надо данные обновить. Пока дойдём до чтения в main, этот стакан изменится десятки раз. И все изменения кроме последнего - бесполезные.

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

О какой секунде речь - не понятно. Если речь про транзакцию, то после её подачи по номеру происходит поиск записи в таблице ордеров сразу, мгновенно. OnTransReply нужен только для того, чтобы прекратить поиск, если есть ошибка. Еще раз в момент принятия решения Вы просто смотрите на данные. Других данных у Вас нет.

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

Вы исходите из того, что колбек в Квике - это гарантированное событие. Но это не так. Одно это уже заставляет просто даже не смотреть в их сторону. Потом скорость и асинхронность - я не очень понимаю этот довод, т.к. это тоже не гарантирует получения консистентных данных. Смотрим в сторону CAP теоремы. Колбек может прийти как до момента, когда Вам надо принять решение, а может после (а в подходе с ручным контролем можете сами опросить данные прямо в необходимый момент).  Если хотите больше гарантий, то, как минимум, необходимо строить систему, учитывающую команды всех скриптов, принимать решение с их учетом, например, учитывать транзакции по которым еще не получены ответы и данные по деньгам уже некорректны. Но даже если скрипт один, в момент принятия решения Вы не знаете о своем портфеле точной информации, банально потому, что данные которые видите - это прошлое. Настоящее оно на сервере биржи и приедет к вам через некую задержку. Поэтому для некоторых систем уменьшение задержек на 1 млс - стоит того, чтобы проложить отдельное оптоволокно сквозь горы.

Я использую такой же подход. Тем более что сканировать таблицы необходимо в любом случае при старте скрипта.

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

Мои наблюдения тоже по брокеру Сбербанк. После принудительного обновления на последнюю версию, старт терминала стал очень долгим. Но не сам старт, а загрузка данных. Запуск и показ окна - это секунд 15. У меня не так много открыто окон. А вот потом начинается реальный тормоз. Примерно минут 5 уходит на загрузку данных, это видно по времени последнего пакета и времени сервера в строке состояния. Оно скачками изменяется и отстает на минуты 2 пока все не загрузится, и только тогда оно начинает изменяться по секунде. Т.к. скрипты стартуют с терминалом, то в момент долго старта явно видно, что обработка действий с таблицей происходит не то что медленно, а можно увидеть как обновляется информация построчно. Вспоминаю времена Word 2.0 на 386.

Рядом брокер от Альфа, они на версии 12.5 - запуск секунд 5, работа возможна практически сразу, по крайней мере, запускаясь вторым после Сбера, и пока он думает, здесь уже скрипты проверили данные и подали транзакции, ордера установлены. А Сбер так и думает пока.

Sleep здесь вообще не важен. Тем более, что если уберете его из main, то Квик банально встанет, что не говорит в его пользу и организацию работы с потоками.

Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.

Может и не надо. Ремарка была, т.к. прозвучало, что это потокобезопасно. Не более.

Мы не знаем как реализовали доп. поток в Квик. Реализовали ли макросы lua_lock вместо заглушек в lua исходниках. Хотя в этой давней теме https://forum.quik.ru/forum10/topic3270/ обсуждалось, что таки реализовали.

Да, но потокобезопасность - это гарантия, а не вероятность.

Потому что в момент получения размера, другой поток изменит last или first

-- Текущий размер очереди ---
function QueueSize(self)    return self.last - self.first + 1  end

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

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

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

Когда я говорил о двойной очереди, я говорил именно о двух очередях.

Да ничего здесь нет глобального, просто кушать хочется. У Финама как было 45 копеек за контракт, так и осталось. У кого-то 1 руб. А другие решили, что процент от стоимости контракта - это способ убрать всех с срочки, т.к. для дорогих контрактов комиссия выходит просто гигантской. 0,015% от стоимости контракта - это "космос". Хотя, как ни странно, для опционов 50 копеек так и осталось.

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

Если речь про глубину в 50 линий, то это давно у кого есть. Просто Сбер всегда выдавал 20 линий. После изменения комиссий у Сбера на срочном рынке - этот брокер только для Фонды. Платить в десятки раз больше за контракт - это безумие.

Так наступают времена, когда терминал останется только для проф. участников. Остальных попросят на выход. Альфа уже Квик выдает только квалам.
Был бы нормальный единый API давно бы уже ушли. А так пока у всех свои изделия, то проще через Квик. Но сдается мне, что Если ARQA не начнет реагировать, то это сделают другие.

DestroyTable нельзя вызывать в колбеке окна - это отражено в документации.
Вызывать OnStop руками, тем более в колбеке окна - тоже не надо.

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

Этот колбек самый опасный. Читать таблицу обезличенных сделок лучше пакетами. У Вас цикл работы скрипта. допустим, 100 млс. За этот период набежит много сделок. Дойдете до процедуры чтения и все пачкой прочитаете от прошлого индекса. И так читаете, опрашивая не изменился ли размер таблицы. Колблек же будет занимать основной поток терминала просто говоря, что прошла сделка.

Свою.

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

Поэтому можно, и нужно, формировать разные очереди. И даже в рамках одной очереди, лучше использовать две, разбивая их на четные и нечетные. И писать, читать поочередно.
Записал в четную, потом в нечетную, потом четную, нечетную.
Читать нечетная, потом четная и т.д.
Это частично может помочь избежать блокировок. Или просто случайным образом выбирать какую очередь использовать первую.

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

А зачем писать на диск, если mmap позволяет делать отражение в памяти.

Проверяйте, что не производятся расчеты в колбеках. Очень часто - это основная проблема. Более корректно - формировать очередь сообщений и разбирать в потоке main.

Но по субъективным ощущениям могу подтвердить, что последние версии терминала стали более легко уходить в ступор.

Не совсем так. Это ближе к чтению из таблицы текущих торгов. Если стакан открыт, т.е. поток данных уже есть, то можно читать без заказа. Поэтому и есть метод проверки существующего потока.

Колбек нужен для определения, что данные изменились. Если надо просто прочитать, то особого смысла в нем нет.