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

В моей текущей реализации системы, это модуль  Watchdog, задача которого обеспечить непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо".
И пусть цена идет куда угодно, пока состояние ни восстановлено, так как принимать решение все равно нельзя. Собственно это и есть механизм защиты от 10 сигма.

Nikolay,  Рассуждения мои сводятся только к 3 коллбекам исполнения, дальше просто не заглядывал. Модель светофор не рассматривал, хотя показалась интересно нужно "покумекать".
Вы правы соображения субъективны, все выкладки чисто теоретические, так как систему только собрал еще даже не запускал. В соседней ветке описал от куда ноги растут.
Задача стояла быть уверенным что на какой то момент времени можно утверждать что все данные пришли. алгоритм "Рекомендация от разработчиков проста - взяли данные в колбеке и передали в main, и уже там с ней работает". То есть колбеки уже напихали нам отфильтрованную информации, работаем только с ней. Ну тут даже интуитивно видно что подход более оптимален, нежели описанный в примере от TGB. Обработку таблиц вызываем когда система само диагностировала несоответствие данных. 6 инвариантов или можно сказать 6 фазовых состояний замкнутый цикл. Все.
Да же если допустить, что событие несоответствия данных частое, то система перейдет в состояние опроса таблиц.

Здесь хочу добавить что рассуждения строил  от приказа стоп - лосса, но так как он в QUIK такой же лимитный, то все просто расширяю на исполнение всех лимитных ордеров?

Temporal Logic of Actions (TLA+) - метод, который взят за основу, — это не академическая теория, а активно используемая инженерная практика.

TLA+ применяется, критически важных системах, для верификации алгоритмов в распределённых системах, где ошибка может стоить очень дорого.
Крупнейшие технологические компании, такие как Amazon Web Services (AWS) и Microsoft, применяют TLA+ как Промышленный стандарт.
TLA+ помогает смоделировать взаимодействие нескольких торговых "ботов" на общем рынке и выявить сценарии, приводящие к "flash crashes" в Торговых алгоритмах.
Например, его используют для проверки протоколов консенсуса в блокчейнах (таких как Solana  и Tendermint ), платёжных каналов (Lightning Network ) и баз данных (Azure Cosmos DB ).

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

В моей текущей реализации системы это просто аналогия,  Watchdog — это непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо".

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

Следовательно. Мы можем построить абстрактную модель системы на TLA+. Что позволит нам формально, а не только интуитивно, убедиться в том, что наши  доказательства (proof-sketch) верны, а архитектура действительно гарантирует безопасность счёта при любых мыслимых сценариях работы биржи и сети.

И это совершено иная концепция безопасности. "Ни гадать а быть уверенным"!

TGB,  Не я не понимаю иногда то что Вы пытаетесь донести как истину в последней инстанции. А я бывает и ошибаюсь, читаю тех. литературу и пересматриваю подходы. Но так как Вы тему отказываетесь комментировать то смысла нет перепираться. Либо приводите убедительные доводы.

TGB, За ссылку спасибо, но там столько не понятных для меня слов, что не хватает моей компетенции разобраться. За то хватает их чтоб прокомментировать Ваше сообщение выше. Глобально свое мнение не поменял. Прокомментируйте почему вдруг    "призрачные" коллбеки (зависящие от кода main)?
Как все реализовано разработчиками посвящен целиком этот сайт, а у меня даже мысли бы не было лезть туда куда ни надо.

Речь о двух независимых потоках, QUIK / колбек и Lua / main.
1. Колбеки прилетят быстрее факт очевидный пусть даже с маловероятным событием пропусками.
2. main мы вынуждены тормозить искусственно чтоб передавать управление ЦП. Вызывая обработку таблиц из цикла маин мы должны учитывать как минимум эту задержку?
3.  Сама система может находиться в 6 состояниях (модель куб состояний, где 8 вершин - фазовые переходы, 6 граней те самые инварианты), система замкнута следовательно может находится только в этих 6  состояниях. Кода находит расхождения в данных, она  восстанавливает данные путем уже опроса таблиц. Так как событие редкое то и опросы редки.
Все это и позволяет мне утверждать что будет более надежно обработано большее количество инструментов за меньшее время.  
Есть еще конечно и сама инженерия кода, но ведь обязательно кто то создаст надежный.

А что тут комментировать, ЧУШЬ полная! Да и обсуждение совершенно о другом.

А этого Вам не достаточно, или какие то слова не понятны?

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

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

Если есть конкретные проблемы (например, потеря OnTrade), событийная модель может их решить элегантнее, чем простое увеличение таймаутов. Но если текущая система вас устраивает — нет смысла её усложнять.

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

Таким образом, событийная модель не требует надёжности колбэков — она лишь использует их для уменьшения задержки!

Nikolay,  CAP-теорема говорит, что в распределённой системе мы можем выбрать только две из трёх характеристик:
* Consistency,
* Availability,
* Partition tolerance.

Биржа — это отдельный узел, с которым у нас нет синхронной связи.
Мы выбираем Availability и Partition tolerance, жертвуя строгой консистентностью в реальном времени.

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

Именно это дают, в моем варианте, инварианты S1‑S6 и Watchdog.

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

TGB, А какие слова для Вас не понятны? Повторюсь, безопасность счёта можно доказать математически, событийная модель с инвариантами и реконсиляцией — единственный известный путь.

TGB, Дело несколько в другом. Действительно, колбэки в QUIK не являются гарантированными, и любая система, работающая с реальной биржей, сталкивается с задержками, потерями и недетерминизмом. CAP-теорема здесь работает в полную силу, в распределённой системе, где биржа — это внешний, неподконтрольный нам узел.

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

Напротив, она предназначена именно для того, чтобы жить в мире, где события могут теряться, приходить не в том порядке или с задержкой. Разница между вашим подходом (опрос таблиц + OnTransReply) и событийной моделью не в том, что событийная модель предполагает надёжность колбэков, а в том, как она обрабатывает неопределённость!

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

TGB, Описаный Вами подход не хуже и не лучше — он просто другой. Он проще и для многих задач работает, а может даже и оптимален.

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

Могу привести еще недостатки Вашего подхода, но прислушаюсь к совету

Ну говорить про этот подход и не сказать про его ограниченность, как минимум не корректно.  Для простых систем да. А если у вас несколько стратегий на разных инструментах, таблицы обновляются асинхронно. Вы не можете гарантировать, что в момент принятия решения о новой сделке все кеши консистентные, то есть согласованные. Особенно остро это проявляется при работе с лимитами риска, вам нужно точно знать суммарную позицию, а она может временно «плавать» из‑за задержек обновления разных таблиц.

Ну или просто банально OnTransReply может потеряться. Вы ждёте 120 секунд — это огромный интервал. За это время рынок может уйти далеко, а вы всё ещё не знаете, исполнилась ли заявка. В результате вы можете пропустить возможность или, наоборот, ошибочно считать, что заявка не прошла, и повторить отправку (что приведёт к дублированию)?

Ну почему ни чего? Можно попробовать, двухэтапную обработку с таймаутом, решение более надежно.  Ваша текущая проверка на trans_id верна, но её просто недостаточно для гарантированной обработки всех сделок. Попробуйте, внедрение кэша с таймаутом — это стандартный паттерн для работы с асинхронными и ненадежными потоками событий?  

https://forum.quik.ru/messages/forum10/message27375/topic3157/#message27375

"В последнее время несколько раз наблюдал такое: приходит OnTrade, в котором trans_id=0. Я знаю, что это промежуточная версия, поэтому в мой алгоритм вписано игнорировать такие вызовы, ожидая более полных. И почти всегда они приходят. Но в среднем 1-2 раза за день случается так, что полный OnTrade с ненулевым trans_id так и не приходит. В чём может быть причина?"
Ответ очевиден может.

Ситуация, которую вы описываете, связана не с багом в вашем коде, а с особенностями того, как QUIK и брокерский шлюз доставляют информацию о сделках. Подобную ошибку в событийной модели допускают даже грамотные, опытные разработчики на QUIK. Используя "умную заявку" (один trans_id=const на весь жизненный цикл инструмента, для 3 таблиц) в своих подходах, отлавливал такую же проблему.

Почему полный OnTrade может не прийти? То, что за день теряется 1-2 полных события, — это тревожный, но, к сожалению, не уникальный случай для распределенных систем.

Вот наиболее вероятные причины:

 * Потеря пакетов на сетевом уровне: Система QUIK и брокерский шлюз обмениваются большим количеством данных. В условиях нестабильной сети или высокой нагрузки пакет со вторым, полным, событием мог быть просто потерян.

 * Сбои в очередях событий QUIK: В самом терминале или на стороне брокерского шлюза есть очереди событий. При переполнении или внутреннем сбое часть событий может быть отброшена, не доходя до вашего скрипта.

 * Особенности логики брокерского шлюза: Хотя это менее вероятно, существует возможность, что в редких случаях логика шлюза, отправляющего два события (служебное и полное), дает сбой, и второе событие не генерируется.

Наверняка список можно расширить.

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

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

Или вот это, До обсуждались, про супер: А Не смущает то что мы ее задаем и вынуждены контролировать? Постоянно так Quik Ни чего нигарантирует?

А вот это обидно! А Вы уберите sleep   и по рассуждаем чья инженерия кода лучше?

Это маленькая толика, возможных ситуаций, довьёт еще свои. и будем обсуждать Ваши, подход ваш так себе.

User12501, Скажите на русском читаете, если нет, то какие слова Вам не понятны

Так ведь и двойная очередь ограничена количеством элементов, для этого и храним первый и последний индекс. Лично меня всегда смущает в кольцевом буфере не явная индексации, "под ложечкой ноет" а тот ли элемент получен в расчетах. В то время как в двойной все линейно.

Вы рано радуетесь все работает не корректно в части секции срочного рынка

Спасибо действительно. Здесь видимо дело вот в чем, ломается глобальный 30 летний тренд "Carry Trede", все разом поменяли маржинальные требования. А товарные рынки перекредитованы больше всего.

У себя даже собрал рабочий “BoJ-радар” в TradingView, как систему ранних предупреждений. Цель: увидеть глобальное сжатие ликвидности за 1–10 дней до падения рынков.
Все просто на грани, а ниточка на которой все весит тоненькая. Стоит  BoJ пошевелить в сторону увеличения, и "медный таз" неизбежен, накроет.

Я торгую лимитными ордерами а там 0 за сделку.

Но согласен, брокер не для срочного рынка. Вот и смотрю куда податься, без ответственность ARQA и смешивания всего на брокеров приводит к тому что чудят все брокеры. Вот и хотелось бы понять кто в меньшей степени. Стоит менять "Шило на мыло"?

А Стакан 50 очень удобно  я им активно пользуюсь на срочном, супер!

Начал искать куда бы сбежать от этих "талантов", так ка и другие чудеса демонстрировали без стеснений. Обратил внимание на ВТБ, не стакан а целая книга ордеров на срочном? Кто торгует поделитесь мнением?

Izotova Liliya,  И причем тут рабочее место? Чудит брокер Сбер. А виновато рабочее место. Проблемы ТРЕТИЙ день с лимитами на срочном рынке, Ни чего не отображается. Допустим у меня просто пропал торговый счет == коду клиента.

nikolz,  Вывожу по основному счету и фильтрую по виду, так хоть количество видно, а денег нет? Вот чудеса, а Сбер брокер самый "талантливый", у других брокеров проблем не вижу.

TGB,  Ну так это же просто двойная очередь, с которой я разбирался и только ленивый меня "по столу носом не возил". Более медленный вариант, чем скажем кольцевой буфер? Можете архитектуру привести или пример?

Просто разбираюсь с тем же самым, и вот что удалось выяснить не который слой ошибок. Почему роботы закрываются "просто так" и как это фиксят в проп-торговле?
Это класс ошибок, который случается даже с идеально спроектированными системами. И причина всегда одна: > Расхождение между биржевой реальностью и состоянием в QUIK!

Вот конкретные механизмы  (примеры).

1. Главная причина: Асинхронность данных в QUIK. Здесь помним QUIK — это клиент терминал, а не биржа!

Время в QUIK ~= Время на бирже
local q_time =  -- локальное время QUIK
local e_time = -- время биржи (если доступно)
Разница может быть ~ 0.1-5 секунд, а то и более!

Что происходит:
1. Биржа. Цена прошла стоп > стоп сработал;
2. QUIK (через 0.5-2 сек). Получил тик > показал в стакане;
3. Робот. Увидел в стакане > решил "стоп сработал";
4. Но, Стоп уже сработал на бирже, а в QUIK ещё не отобразился.
Результат: робот пытается отменить уже исполненный стоп > получает ошибку!
--------------------------------

2. "Призрачные" стопы в QUIK. QUIK показывает активный стоп.
stop_order = getItem("stop_orders", index)
if stop_order.flags == 1 then
   -- Считаем активным
   -- Но на бирже он мог уже сработать!
end

Это случается при:
* Лаге данных (биржа > шлюз брокера > QUIK);
* Частичном исполнении (часть уже исполнилась, QUIK ещё не обновил qty);
* Ошибках протокола (QUIK не получил подтверждение удаления).
--------------------------------

3. Классический кейс рассинхрона. Таймлайн (реальный):
[00:00.000] Цена Bid = 100 000 (на бирже)
[00:00.100] Цена достигает стопа 100 000
[00:00.150] Биржа исполняет стоп
[00:00.300] QUIK получает обновление стакана
[00:00.350] Робот видит Bid = 100 000 > думает "стоп ещё не сработан"
[00:00.400] Робот пытается изменить стоп > ошибка

Извините, странно работает сегодня сайт у меня. Возможно так понятней:

local function round(num, idp)
 
  -- Если num некорректное, вернуть как есть
  if not num or type(num) ~= "number" then return num end

  -- Если idp не указан, использовать 0 (округление до целого числа)
  idp = idp or 0
  local mult = 10^idp

  -- Универсальное Округление для любого числа
  local rounded = num >= 0 and math.floor(num * mult + 0.5) / mult or num < 0 and math.ceil(num * mult - 0.5) / mult or 0
 
  -- Если число целое, убрать .0
  if rounded == math.floor(rounded) then
      return math.floor(rounded)
  end

  return rounded
end

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

Если в двух словах, так мониторю интернет. Кроме любителей для частного использования, пишут и применяют подходы:
1. Проп - трейдинг. Управление капиталом до не большой суммы M руб, несколько инструментов одновременно, с Квартальной надёжность > 99.9%;
2. Алготрейдинг для фондов. Обязательно исполнение крупных заявок (iceberg, TWAP), хеджирование портфелей, арбитражные стратегии;
3. Инфраструктурный проект. Базовый фреймворк для других разработчиков, возможное решение для брокеров или платформа для обучения risk-менеджменту.
Такие системы называю - промышленный уровень, так как к ним предъявляются более жесткие требования.

Эмуляция разных видов сбоев QUIK, приводит к необходимости оценки не только кода. Что должно подлежать оценки и что оцениваю в настоящий момент: Архитектура, Надёжность, Безопасность, Производительность, Production готовность, Общая оценка на соответствие - Промышленному уровню..

ВЫВОД: в условиях ограничений QUIK нужно создать система, которая отвечает следующим требованиям:
*  Признаёт реальность - QUIK ненадёжен, и мы строим защиту;
*  Разделяет ответственность - каждый компонент делает одно дело;
*  Самовосстанавливается - любая ошибка не фатальна;
*  Гарантирует безопасность - риск никогда не увеличивается;
Это пока база. Нужно добавить Session Risk Manager, система станет законченным продуктом уровня проп-десков?

А это уже подход не просто робот, а торговая операционная система. Чувствуете разницу? То есть, можно запускать любые стратегии с гарантией безопасности исполнения. И это ключевое в подходе!

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

А задача стоит, приврать систему если не в «надежную» то, в предсказуемо безопасную и рассуждая о ней как о risk - engine, а не просто коде? Что думаете не возможно?

Сказать "Просто" - это просто, сделать, вот вопрос. Отлавливая ситуации при которых квик может похоронить все твои начинания, превзошли все мои ожидания! Не ведь, крутился же скрипт, да и ладно.

Проверка подхода, надёжной архитектуры: "FSM + события терминала как единственный источник истины",  приводит к такому количеству ситуаций, при которых сервис если не падает, то надежным точно не назовёшь. А ведь задача отслеживать позиции и их защищать, в круглосуточном режиме.
Нет и уверенности, что все причины возможных сбое установлены?
Другой вопрос возникает, а снимут ли корутины часть проблем?

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

dimka,  По пробуйте, выводить значения индикатора, используя этот подход. [CODE][local function round(num, idp)
   
   -- Если num некорректное, вернуть как есть
   if not num or type(num) ~= "number" then return num end
 
   -- Если idp не указан, использовать 0 (округление до целого числа)
   idp = idp or 0
   local mult = 10^idp

   -- Универсальное Округление для любого числа
   local rounded = num >= 0 and math.floor(num * mult + 0.5) / mult or num < 0 and math.ceil(num * mult - 0.5) / mult or 0
   
   -- Если число целое, убрать .0
   if rounded == math.floor(rounded) then
       return math.floor(rounded)
   end

   return rounded
end/CODE]

Просто решил переписать выставление стоп - лосс. Не  просто «скрипт», а сервис сопровождения позиций. Архитектура stop-manager для QUIK как конечный автомат (FSM).
В QUIK такой подход, единственная надёжная архитектура: FSM + события терминала как единственный источник истины?

Создаем источник данных:
local ds, err = CreateDataSource(...)
После ~30–80 инструментов в QUIK возникает потенциальная утечка?
Что в свою может привести: начнет тормозить, потом перестанет обновлять бары?
Тогда возникает вопрос простой а где и когда правильно ставить ds:Close()? На что держать ориентир?

Дело обстоит далеко не в величине коррекции или то что она приходит на смену тренду. Картинка проставленная выше VPM, подходит как как для графика серебра так и золота.

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

Вы о чем? Из Вашей картинки ничего не понятно.

nikolz,  На мой взгляд это из одной области и все туда же к "Сивой кобыле". Ну вышла и вышла, еще показать себя надо. Ну или падение на 1.2%? Даже комментировать не буду.

А вот что важно, не найти. На пример почему Шанхай дает премию по серебру ~ 30$ за унцию серебра? Куда реки текут? На наших глазах делаются состояния. А расскажут потом. Но я собственно ответы нашел и тема стала не интересна.

Сказочка номер два.
Очухались наши фундаменталисты и начинают хоть какие то разумные факты приводиться. Если в двух словах, то смысл следующий: Представим большую комнату по средине один стул и 350 участников пытаются на него присесть. Именно во столько иксов оценивается дефицит на фактическое серебро. Ну или примерно во столько раз, здесь уже не важно сколько иксов, важно что существут дифицит и со стула будут друг друга спихивать. А фантики жечь на костре.

Нашлись и миллиарды зеленых, их просто пере парковали в юани. Интересный факт вызывает еще один момент. Запасы золота Центробанков стран "колонистов" находятся на уровнях ~ 65% (для примера в РФ ~30%)!  А как дела во второй экономике? Называется оценка порядка 8% хотя гребут все последние годы, и цена их ни очень смущает. И при этом строится мировая валютная инфраструктура, в том числе и "автомагистраль" параллельная, дороге под названием SWIFT. Вот в общем то все и стало на свои места, "богатые богатеют бедные беднеют". Вот и сказочке конец, а кто слушал молодец! Всем хорошей торговли.

Время сказочек наступило, моя для тех, кто торгует фьючерс на золото.

Сказочка раз - "Наш паровоз вперед летит, в коммуне остановка ...". Вот и рынки золота и серебра.

Данные события наверняка попадут в книги как исторические события 29.01.26 г., и позже будет высказано много мнений, по этим ситуациям. Но сегодня ничего не найти. У меня была открыта небольшая позиция в лонг на GOLD - 3.26, в конец основной торговой сессии (MOEX)  пятница. Наблюдаю такую картину: Просто как по команде начали закрывать позиции, а деньги выводить с рынка, крупными участниками. В разы увеличились "медведи" и куда то подевались "быки" (не кроме меня конечно). Сам торгую технический анализ, и ни чего не понимаю, что происходит фундаментально. Поискал новости - Предполагаемая смена главы ФРС, ну бред "сивой кобылы"! Так как моей цель был гэп понедельника, оставил позицию. Это и сделало меня не просто наблюдателем - участником.  Эти удивительные фундаменталисты, от куда только "не трубили" о приобретениях, и ни чего в исторический момент?
Про то как все было дальше в общем то не интересно. А вот что интересно, остановка - "коммуна". Всего лишь нажата кнопка: "Повышения маржинальных требований", и колеса паровоза закрутились в обратную сторону, а стоимость билета превратилась в триллионы зеленых. Нужно тут добавить, что после этой бумажной манипуляции, спрос на фактическое золото и серебро не упал, и по всей видимости они в дефиците, но это уже к нашим коллегам фундаменталистам.
Почему исторический - такой или примерно такой сценарий  уже исполняли и не раз. А быть участником каково?

"Разделяй и Властвуй"

Вновь и вновь возвращаюсь к примеру автор Nikolay №558,  Назову его "ФУНДАМЕНТАЛЬНЫМ" для QUIK / QLUA. Попробую разобраться с подходом, что здесь за модель и как из неё сделать универсальный боевой модуль, не сломав фундаментальные допущения?

Что уже реализовано — это кооперативный неблокирующий планировщик задач (cooperative task scheduler) в одном Lua-потоке, с:
* отсутствием ожиданий по времени;
* отсутствием блокировок;
* отсутствием предположения о задержке (assumptions о latency);
* прогрессом по факту изменения состояния.
И это НЕ очередь задач в классическом смысле. Это конечный автомат, опрос, управляемый событиями, (event-driven polling FSM).
Главное архитектурное решение (и оно единственно верное): > Мы не знаем, сколько времени займёт операция. Следовательно,

Нельзя:
* sleep(n)
* while not ready do end
* «ждать 30 секунд»
* «ждать 2 минуты»

Можно:
* проверять факт изменения состояния;
* делать это часто;
* не блокировать выполнение.

В коде "task" — это: > Объект проверки состояния, а не операция.
task.process = function()
   if условие_выполнено then
       return done
   end
   -- иначе ничего не делаем
end

И это принципиально, по следующим причинам:
* task.process() не делает работу,
* она проверяет, завершилась ли работа,
* сама работа выполняется вне task (QUIK, брокер, сервер).

И это правильная модель для:
* DataSource;
* транзакций;
* подписок;
* внешних сервисов.

Почему модель классная, а главное масштабируется. Очень важный плюс текущего подхода:
* можно иметь 100 DS
* можно иметь 1000 задач
* ни одна не блокирует другие
* все живут в одном цикле

И это уже:
* не потоковая модель;
* не callback-ад;
* не FSM в лоб.
Это кооперативная многозадачность, и для QLUA она оптимальна! Ну хоть и "опосля", ну доходит!

Главный вывод (ключевая формулировка).

Этот пример кода — с: > Неблокирующий кооперативный планировщик проверок состояния внешних асинхронных процессов. И это ровно то, что нужно для:
* DataSource;
* транзакций;
* брокерских ответов;
* пользовательских команд;
* UI;
* логики стратегий.
и что там еще нам нужно в нашей деятельности.

Это изначально, выбор правильного фундамента. И тут можно было бы закончить, поблагодарив автора за столь мощный "ФУНДАМЕНТАЛЬНЫЙ" пример.

Но от себя добавлю, что бы идти дальше и правильно, остаться в парадигме "один список задач", идея так себе — тупик в бою, и вот почему. "Один список задач" хорошо работает, пока:
* задач мало,
* они однородны,
* нет вытеснения,
* нет зависимостей,
* нет приоритетов,

Как только появляется:
* DS, которые живут часами,
* транзакции с неопределённым задержками (latency),
* стратегии, подписанные на бары,
* команды пользователя,
* аварийные события.
список превращается в плоскую кашу, и дальше начинается:
* If-ад
* флаги поверх флагов
* неявные зависимости
* ошибки, которые невозможно воспроизвести

Кто это знает, кто уже туда смотрел, и переходит к формированию задачи "планировщик + типы задач (DS, TX, UI)".
Вариант 2 — естественное развитие кода, возможно даже единственно правильный подход для боевого модуля?

Танго,  Попробуйте так:
-- вывожу в таблицу
-- SetCell(TableNaladka,2,2,actualPrice);

Ок, спасибо Izotova Liliya, все так!

Izotova Liliya,  Пользуясь случаем подскажите, при этих настройках я смогу  заказывать получать эти данные с помощь функции CreateDataSource используя четвертый параметр? Или этого недостаточно? За ранее благодарю!

Все подгрузилось на графики, но теперь не понимаю радоваться этому или нет? На сколько скорость терминала упадет, и главное тут чтоб сам устоял, "ни пал лицом в грязь".

"Не что не вечно под луной". Заглянул в настройки котировок, а там классов по "наплодили"   ,  какие торговые, за полгода не разобрать? Пробежался вроде все нужны, парочку только отключил.

Izotova Liliya,  Спасибо принято, действительно упусти этот момент, надеюсь, что и терминал теперь загрузится.