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

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

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

Любопытства ради небольшой тест, тксть поверим теорию практикой (вариант с длл писать лень)

Это не я, это арка.

Гарантийный же случай? )

Вызов функции не то чтобы тяжелая операция. Грубо ориентировочно наброшу цифр.

Если функция находится в длл, луа перед ее вызовом снимает лок, а после - снова захватывает, это самая тяжелая часть вызова (самого по себе вызова, не тела функции). Пара EnterCriticalSection/LeaveCriticalSection занимает порядка 100нс, новее железо - меньше. Всем остальным оверхедом вызова в сравнении с этим можно пренебречь, т.е. время на порядок меньше. Ок, чтобы получить оверхед в одну секунду, надо сделать порядка 10 миллионов вызовов функций из длл в одном цикле без слипов и прочих ожиданий.

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

Резюме: вообще не о чем париться.

Это вопрос архитектурный. Варианта два.

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

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

Третий вариант это как тут часто в вопросах попадается, когда смешали все в кучу и получилась, естественно, куча.

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

Не совсем оно так, стейт для тела скрипта и колбеков один и выполняется в основном потоке квика, стейт для мейна второй и выполняется в специально для него созданном потоке. То есть ваш п.1 лишний, нет отдельного стейта для тела.

Ваши мысли насчет 128 ядер это из разряда давайте загрузим проц бесполезной работой, чо он простаивает-то. В любом случае ваши 100500 потоков будут сериализоваться на доступе к общим ресурсам, т.е. в основном (в таком количестве) они будут крутить спинлок. Для примера предлагаю прогу из directx sdk, где можно отрисовать одно и то же либо одним потоком, либо многими. Запустите и убедитесь, что проц оно жрет в N раз больше, а fps растет процентов на 5.

Исхожу из такого соображения: если автор индикатора хочет (только) целое, он инициализирует целым и тем самым отрезает юзеру возможность вбить что-то нецелое. Пример: для ema можно использовать дробный период, для sma - нельзя. Пусть во втором случае юзер вбил дробное число, как ему теперь посигналить, что число будет округлено до целого? Он же ж останется в уверенности, что у него sma с периодом 3.14, а она с периодом 3. С целым нет проблем, он просто не сможет вбить 3.14 и это сподвигнет его задуматься, то ли он творит.

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

В традиционное "раньше было лучше" внесу диссонанс: давняя проблема с неочисткой памяти при ошибке в OnInit наконец решена. Четенько все подчищается. Ура товарищи и спасибо за исправление.

Дык это фулл ордер лог. Аналог ТВС это тип C.

Косяк это.

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

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

Потому что надо различать "дата" и "дата торгов". Первое это когда сделка фактически произошла, второе это в какую сессию она будет учтена.

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

Отдельную табличку для вечерки, отдельную для дня, не?

Табличка в приложении 1 говорит таки о TOM.

Через iss. Там базовый актив в поле assetcode и там внезапно GAZR. Про спектру, ежли уж на то пошло,
, но показать/посмотреть не могу, может там тоже GAZR окажется.

Действительно. И getSecurityInfo тоже. Получается, что ответ с анекдотом - вариант раз, ответ с "читаем спецификацию" - вариант два. Как ни странно, гипотетический вариант три - "качаем листинг напрямую с мамбы" - не сработает, там тоже (в общем листинге) базового нет. Видимо, квик сам оттуда и тащит.

уже написан в первом сообщении темы.

В luacdll.lua должно быть буквально следующее

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

Запустил у себя
- все ок. Что-то локально-брокерское может быть, в связи с нововведениями?

А на стакан подписывались?

Проверил, нули. Что было раньше не знаю => когда началось сказать не могу.

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

Есть еще вариант пульнуть фейковый стоп по нереальной цене и подождать ответа, тксть протолкнуть им. И снять тут же, конечно. Фактически сымитировать тот самый флаг "ответ приехал". Но датасорец, конечно, так не протолкнешь.

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

Да, об этом не подумал. Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.

Вытащите из Program Files в корень диска или еще куда, где на запись доступно.

Думаю, сервер получил от шлюза уведомление, ткнулся его переслать клиенту, а там дисконнект. И выбросил. Гарантированная доставка это что-то типа MQ, сомневаюсь, что в квике так сделано.

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

Они едут в ТВС всей (заказанной) толпой, по отдельным датасорцам их клиент должен разбирать, так что серверу тут нечего отправить в качестве текущего количества свечей по конкретному тикеру. Можно даже предположить, что он и по всей ТВС затруднился бы сказать, сколько у него тиков в моменте.

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

Все он понимает, но ему-то придется думать, как минимум, как эту схему на тики распространить. Я вот не придумал так сходу. Пока не будет точно ясно, скока вешать в граммах, будут общие фразы "когда-нибудь рассмотрим и подумаем". Когда что-то четко формулируется, они сразу же это и делают. Соответственно если хотим что-то получить, надо это что-то обсосать до реализуемого вида, подход "мне все равно как вы будете делать" работает против пожелателя, бо раз все равно, то "никак" тоже вариант.

Так-то мы и без специального уведомления знаем, что данные может когда-нибудь появятся, ну может через неделю, а может и нет. У меня созрела схема получше, давайте попробуем на нее посмотреть. В датасорец добавляем функцию ds:ExpectedSize. Сразу после подписки там nil. Когда сервер что-то посылает по подписке, он также добавляет поле с количеством свечей у него в данный момент. То есть в каждом пакете отправляемом. Как только первый пакет с сервера приехал, это поле становится доступным через ds:ExpectedSize(), далее с каждым пакетом это поле обновляется. Старая ds:Size() продолжает работать как работала, это количество свечей в хранилище у клиента. Что мы получаем в итоге. После подписки, пока ds:ExpectedSize() возвращает nil, мы знаем, что подписка отправлена, но ничего еще не приехало. Потом что-то приехало, пусть одна свечка, ds:Size() дает 1, но ds:ExpectedSize() дает больше, ок, мы знаем, что надо еще подождать. Либо на сервере нет свечей, тогда ds:ExpectedSize() возвращает 0 и мы знаем, что ждать в данный момент больше нечего. Либо мы получили все что есть и ds:ExpectedSize() == ds:Size(), дальше, если хотим реалтайму, никто не запрещает поллить периодически или настроить колбек. В чем-то перекликается с предложениями от Nikolay выше. Правда, не очень представляю, как это будет с тиками работать, они ж по каналу ТВС едут, там свои погремушки.

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

можно бы предложить возвращать из ds:Size nil вместо нуля, пока с сервера что-нибудь не приехало (хоть бы и ноль). Но сколько народу на это наступит и сколько будет воплей.

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

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

Видимо да.

Еще б написали, в какой именно восьмой. Луа 53 начиная с 8.5, в более ранних луа 51, видимо в более ранней запускаете.

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

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

Такие вещи надо арке на мыло посылать, а то вот идет прохожий вроде мну, раз и скачивает ваш дамп и глядит, что там у вас... а у вас там квик стоит в C:\Program Files (x86)\Info\info.exe. Собсна вот и ответ. Стоял, видать, 32-битный, обновили сразу на 8.6 и опаньки. Не будет 64-битный в Program Files работать.

Спасибо. Главно дело чтобы мейн опять не сломался при этом )

Да, я об этом )

Надеюсь, вы код писали по памяти чисто для иллюстрации и немного запутались. Ибо если оно вот так в реальности, нилы там закономерны, ссылка-то от luaL_ref в какую таблицу попадет, в ту самую, что вам квик передал на стеке. И тот же luaL_ref ее со стека выбросит. И все, стек пустой, что вы из реестра вытащите вообще загадка великая есть.

Да, конечно. Проверил еще раз на 8.6.0.97 только что, все как было, запускаем - получаем просто ошибку, запускаем повторно - получаем сначала все финализаторы, потом ошибку.

Это вопросы не про квик, а про ядро винды.

Пусть есть сколько-то потоков в системе. Для ядра они все одинаковые, оно не смотрит, это поток из квика или из браузера или еще откуда-то. Часть потоков спит или ждет какого-то события (спит это на самом деле тоже ждет события - таймера), они за процессор в данный момент не соревнуются. Другая часть готова к исполнению, и их (всегда) куда больше, чем ядер. У каждого потока есть некий приоритет, назначаемый при его старте. В ядре винды 32 очереди готовых потоков, по одной на каждый приоритет (которых тоже 32 всего). Каждые 16 мс происходит прерывание таймера, через каждые 2 прерывания очередной поток с ядра снимается и выбирается следующий поток на выполнение. Это будет первый поток из очереди с наивысшим приоритетом. Если высокоприоритетные очереди пусты, проверяются очереди с более низким приоритетом и т.д. С самым низким приоритетом выполняется поток idle, если дело до него дошло, он всякую там приборку фоновую выполняет и, если по-прежнему делать нечего, вырубает ядро, на котором работает. Потом оно запускается следующим прерыванием таймера, опять проверяются очереди, выполняются самые приоритетные потоки, потом потоки похуже, потом готовые потоки кончились, выполнился idle и ядро опять в спячку ушло. Кстати говоря, та "загрузка процессора", что вы видите в диспетчере задач, это по сути сколько процентов времени ядро работало (остальное время оно было выключено).

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

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

В свете сказанного, как может быть, что поток будет ожидать дольше, чем требуется? Придет его очередь - попадет на ядро, сделает сколько успеет и встанет ждать следующего раза. Чем больше потоков, тем длиннее очередь, тем реже поток будет на ядро попадать, с какого-то момента это станет и визуально заметно в виде подлагивания (но не раньше, чем все ядра загрузятся на 100% и заревет вентилятор). Как писал выше, при 1000 потоков на процесс вы этого еще не очень-то заметите, если код написан нормально.

Вы диспетчер задач откройте и посчитайте, сколько там потоков выполняется по всей системе. Сразу увидите, что не совсем логично такие выводы делать. Гуглите вытесняющая многозадачность. Если хотите циферок, то в лохматые годы на хрюше с селероном 1000 потоков в процессе жили припеваючи, с тех пор хуже точно не стало. А так-то можно и один поток так написать, что вся винда колом встанет.

Походу это GDI объекты, там жесткий лимит около 16к штук на всю систему. Интересно, где текут, в квике или в какой-то другой программе.