Последовательность обработки функций обратного вызова
Пользователь
Сообщений: Регистрация: 11.05.2023
01.06.2023 14:51:47
Цитата
Функции обратного вызова обрабатываются в основном потоке терминала QUIK.
Я так понял, что они все ставятся в одну очередь на обработку независимо от функции? Или у каждой функции своя очередь или есть приоритет в обработке? И пока не выполнится предыдущая полностью, следующая не вызывается? Если я например в OnTrade создам заявку и она сразу выполнится, то меня новая OnTrade не прервет? И функция может выполнятся сколь угодно долго и даже задержки в ней можно ставить (но лучше так не делать)? Или лучше по возможности максимально все в main переносить?
Пользователь
Сообщений: Регистрация: 25.09.2020
02.06.2023 00:14:03
Cyber, Да какая Вам разница? Функции обратного вызова по логике своей прерывания, то бишь возникают в случайные моменты времени. Классическая техника обработки прерываний - сделать там лишь самые необходимые действия и умотать оттуда побыстрее, чтобы не столкнуться со следующим. В этом смысле создавать в OnTrade заявки просто безумие. Кстати, OnTrade - единственная функция такого типа, которая нужна для торговли.
Да, лучше по возможности максимально все в main переносить. Техника двух потоков идиотская и глючная. Я в своё время, нахлебавшись этого всего, потратил две недели на перенос всего, что можно, в поток мейна, и с тех пор не припомню ни одного сбоя в работе скрипта.
Функции обратного вызова обрабатываются в основном потоке терминала QUIK.
Я так понял, что они все ставятся в одну очередь на обработку независимо от функции? Или у каждой функции своя очередь или есть приоритет в обработке? И пока не выполнится предыдущая полностью, следующая не вызывается? Если я например в OnTrade создам заявку и она сразу выполнится, то меня новая OnTrade не прервет? И функция может выполнятся сколь угодно долго и даже задержки в ней можно ставить (но лучше так не делать)? Или лучше по возможности максимально все в main переносить?
Если я например в OnTrade создам заявку и она сразу выполнится, то меня новая OnTrade не прервет? Нет. Заявка должна долететь до сервера брокера где ее проверят на достаточность средтств, потом долететь до сервера биржи где ее поставят в очередь, если она не лучшая, и пришлют Вам ответ. --------------------- Механизм обработки колбеков следующий. ------------------------ Все вызовы колбеков выполняются последовательно в одном потоке терминала QUIK. Терминал QUIK открывает 9 потоков. ------------------------------- Но так как информация с сервера брокера (биржи) приходит блоками, то всегда в терминале есть принятые, но не обработанные, данные с сервера. -------------------------- Поэтому, как только Вы выйдите из колбеков в них поступит очередные данные из принятого пакета. Интервал поступления этих данных составляет микросекунды. За это время ваша заявка скорее всего даже не дойдет до сервера брокера и тем более до сервера биржи.
Пользователь
Сообщений: Регистрация: 25.09.2020
02.06.2023 10:51:09
nikolz, Заявка НЕ должна долететь до сервера брокера и биржи и, тем более, вернуться обратно. Вопрос фактически был в том, что будет, если в момент работы OnTrade прилетит новый OnTrade, а для этого вовсе не обязательно посылать оттуда заявку. И ответ на этот вопрос простейший: ПЛЕВАТЬ, что при этом будет, нужно просто максимально минимизировать время обслуживания коллбека - это всё, что может юзер. А раз может, то и должен.
Пользователь
Сообщений: Регистрация: 30.05.2016
02.06.2023 15:58:05
Согласен, коллбеки нужно обслуживать максимально быстро, т.к. во время обслуживания копится очередь из других коллбеков.
В идеале нужно записывать данные в таблицу с индексом и сразу возвращать управление, всю обработку производить уже в main.
Пользователь
Сообщений: Регистрация: 25.09.2020
02.06.2023 16:09:25
Станислав, Именно так. Вот полный код моего OnTrade:
function OnTrade(n) local i; i=a[0][0]+1; a[0][0]=i; a[0][i]={}; a[0][i][0]=n.trans_id; a[0][i][1]=n.order_num; a[0][i][2]=n.trade_num; a[0][i][3]=n.sec_code; a[0][i][4]="B"; if bit.band(n.flags,4)~=0 then a[0][i][4]="S";end; a[0][i][5]=tonumber(n.qty); a[0][i][6]=tonumber(n.price); end;
Абсолютный минимум действий.
Пользователь
Сообщений: Регистрация: 11.05.2023
02.06.2023 16:14:36
Цитата
В идеале нужно записывать данные в таблицу с индексом и сразу возвращать управление, всю обработку производить уже в main.
Это все хорошо, когда БА двигается медленно. Но если нам надо успеть выставить новую заявку за доли секунды после срабатывания предыдущей. Иначе можем нарваться на комиссию биржи. В main можно делать только медленные запросы на сервер, требующие ожидания ответа. Если смешать всё в main, то все станет медленным из-за ожидания ответов. Из-за этого еще может потребоваться делать задержки в main. И перенос в main требует держать глобальные переменные или таблицы в памяти. В разумных пределах выгоднее высокочастотное делать в OnTrade. И очередь из коллбеков НЕ может расти бесконечно, так как новые заявки не успевают выставиться. Самое главное, меня интересует, будет ли эта очередь выполнятся строго последовательно?
В идеале нужно записывать данные в таблицу с индексом и сразу возвращать управление, всю обработку производить уже в main.
Это все хорошо, когда БА двигается медленно. Но если нам надо успеть выставить новую заявку за доли секунды после срабатывания предыдущей. Иначе можем нарваться на комиссию биржи. В main можно делать только медленные запросы на сервер, требующие ожидания ответа. Если смешать всё в main, то все станет медленным из-за ожидания ответов. Из-за этого еще может потребоваться делать задержки в main. И перенос в main требует держать глобальные переменные или таблицы в памяти. В разумных пределах выгоднее высокочастотное делать в OnTrade. И очередь из коллбеков НЕ может расти бесконечно, так как новые заявки не успевают выставиться. Самое главное, меня интересует, будет ли эта очередь выполнятся строго последовательно?
Что-то странное у Вас происходит в main. Мне, наоборот, приходится вводить параметры - число транзакций в секунду, иначе у некоторых брокеров приходит ответ "Превышено максимальное количество 30 транзакций в интервале 1 сек.". И все это в main и никаких колбеков. Колбек как концепция хороша, но если она используется, то должно соблюдаться условие гарантированности доставки. Что нельзя сказать о колбеках в терминале. Плюс многократные технические вызовы оных, плюс исполнение оных в потоке терминала, т.е. есть шанс, что это будет медленно. Не знаю как другие, но раз мы здесь про деньги, то должно быть надежно, гарантировано и воспроизводимо, поэтому я как-то лучше обойдусь без колбеков.
Пользователь
Сообщений: Регистрация: 30.05.2016
02.06.2023 17:06:15
Не нужно вставлять задержки в main, организуйте очередь задач и обрабатывайте их последовательно, возвращаясь к незавершенным (требующим ожидания) задачам уже после.
В идеале нужно записывать данные в таблицу с индексом и сразу возвращать управление, всю обработку производить уже в main.
Это все хорошо, когда БА двигается медленно. Но если нам надо успеть выставить новую заявку за доли секунды после срабатывания предыдущей. Иначе можем нарваться на комиссию биржи. В main можно делать только медленные запросы на сервер, требующие ожидания ответа. Если смешать всё в main, то все станет медленным из-за ожидания ответов. Из-за этого еще может потребоваться делать задержки в main. И перенос в main требует держать глобальные переменные или таблицы в памяти. В разумных пределах выгоднее высокочастотное делать в OnTrade. И очередь из коллбеков НЕ может расти бесконечно, так как новые заявки не успевают выставиться. Самое главное, меня интересует, будет ли эта очередь выполнятся строго последовательно?
На форуме я выкладывал тест,
в котором выставлял и снимал заявки на демо сервере максимально быстро. такая скорость Вас устроит?
Пользователь
Сообщений: Регистрация: 11.05.2023
02.06.2023 18:07:17
Цитата
такая скорость Вас устроит?
Да, вполне. Но на коллбеках она все же выше?
Пользователь
Сообщений: Регистрация: 25.09.2020
02.06.2023 18:41:16
Cyber, Если у Вас много лишних денег, ир можете выставлять новую заявку за доли секунды после срабатывания предыдущей. Подобную хрень я даже комментировать не хочу. Ладно, кусочек ликбеза: НЕ БУДЕТ эта очередь выполнятся строго последовательно. Мало того, будет несколько вызовов коллбека на одно событи, и дубли эти тоже приходят как душе угодно, иногда через несколько МИНУТ.
Нет, Но есть одно но. 1) Так как пишем на луа, то вызов функций стоит очень дорого. 2) Кроме того, большинство любителей используют sleep для предотвращения блокировки ядра процессора пустыми циклами. Я для этого использую события OC, что существенно быстрее. --------------------- 3) Чтобы выполнить действия в main Вам надо распознать какой колбек сработал. И main - это один поток, а колбеков много и инструментов много. В итоге у Вас либо будет пропуск срабатывания колбеков, либо задержка в обработке их сигналов в очереди. ------------------------------ Я решаю проблему путем запуска пула потоков, т е у меня не одна main, а столько сколько надо чтобы обрабатывать колбеки по разным инструментам. В тестах создания снятия заявок для 200 инструментов запускалось до 11 потоков из пула. --------------- 4) Так вот некоторые колбеки быстрее обработать внутри их , чем передавать эту обработку в майн или в пул потоков. -------------------- 5) В потокал пула у меня работают не VMLua, а VMLuaJit + статическая типизация. Это примерно до 100 раз быстрее, чем будет у Вас в main на "чистом Луа" --------------------------------- Поэтому быстрее, чем у меня Вы не сделаете. ------------------
Пользователь
Сообщений: Регистрация: 25.09.2020
02.06.2023 19:11:13
nikolz, За каким хреном кому нужно быстрее, чем у Вас? Ставить и снимать заявки пачками на тестовом сервере - это онанизм. У меня более 90% заявок заканчиваются сделками. Ограничение стоит не более двух заявок в секунду. Всё, что можно, вынесено в поток мейн. Скрипт без напряжения обслуживает тысячу тикеров, а "с напряжением" может и в несколько раз больше. Всё на чистейшем Луа и нет никаких "но". Использую sleep, но не для идиотского "предотвращения блокировки ядра процессора пустыми циклами", а как таймер. Никаких "событий OC", никаких "пропусков срабатывания колбеков", никаких "задержек в обработке их сигналов в очереди", никакого "пула потоков" и прочего дебилизма.
Пользователь
Сообщений: Регистрация: 11.05.2023
02.06.2023 20:22:20
nikolz, я то думал у вас там тест чистого LUA, тогда нее, не хочу такое. Вот и я предполагал, что будет как в п.4 для небольших обработчиков.
Пользователь
Сообщений: Регистрация: 30.01.2015
03.06.2023 07:41:39
Цитата
Cyber написал: , я то думал у вас там тест чистого LUA, тогда нее, не хочу такое. Вот и я предполагал, что будет как в п.4 для небольших обработчиков.
Там тест чистого луа и там в некоторых колбеках выполняется обработка на которую уходит не более 0.001 сек. ------------------------------ А пункты которые я вам написал в качестве ликбеза.
