Еще один вопрос про потоки

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

Поправка
Допустим на одном тике я в меин отправлю push_integer, а на следующем уже в колбэк также отправлю push_string. Не вызовет ли это неопределенного поведения?

Ясно, спасибо!

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

Видимо, плохо я объяснил. Стека два, про мейн я не упомянул, полагая, что и так понятно. Еще раз. Пусть в длл есть колбек и есть мейн:
Обратите внимание, назвал аргументы по-разному, отразив факт, что эти две функции получают разные стейты и, соответственно, разные стеки. Как вы описываете, мейн ждет некого события, потом что-то делает с полученными данными. Пусть мы хотим передать в мейн таблицу, полученную в OnAllTrade. Мы не можем просто взять и lua_xmove ее на стек мейна, потому что мейн в другом потоке выполняется и мы ему просто стек сломаем таким образом. Мы можем действовать по-разному. Во-первых, можем сделать чисто сишную потокобезопасную очередь с событием, распаковать таблицу в OnAllTrade в сишную структуру и сунуть в эту очередь, что разбудит мейн и он что-то там с этой таблицей сделает. Во-вторых, мы можем завести глобальную луа-таблицу в качестве очереди, в OnAllTrade совать туда таблицу и будить мейн, в мейне доставать таблицу и что-то с ней делать. Опять же надо прогарантировать, что мы работаем с таблицей потокобезопасно. В-третьих, мы можем в OnAllTrade просто будить мейн, игнорируя переданную таблицу, а в мейне вынимать все еще не обработанные записи прямо из ТВС циклом с getItem или даже одним SearchItems. В-четвертых, мы можем заякорить таблицу в OnAllTrade с помощью luaL_ref и передать в мейн только индекс в реестре, а в мейне вытащить таблицу из реестра, обработать и luaL_unref ее, чтобы коллектор мог ее потом собрать. Возможны еще варианты, если подумать. Как видите, все варианты предполагают некую синхронизацию.

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

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

Я Вам уже предлагал выше. Напишите конкретно что у вас за ужас со свечами.  (проще задачи не бывает)
Я Вам расскажу как решить Ваш ужас.
 

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

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

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

Все клиенты локальные, далеко гонять не надо. Есть квик и другие источники, они в реальном времени или задним числом, если что-то пропущено, наполняют базу тиков, есть сервер данных, любая желающая аппа цепляется к нему и получает тики сплошным потоком "вот с этой даты" и { "по эту дату" или "в реальном времени" }. В большинстве случаев никакие свечи вообще не строятся, голый тиковый поток используется как есть, но если порисовать чего, то просто на лету в свечки. Объем не так и велик, одна сессия ужимается в десяток мегов, распаковка уже самой клиентской аппой тоже на лету. Часть сжатия там тксть ноухау, поверх него - deflate, как бы одна из причин, почему на луа переделывать - только приключений искать.

Одно время сделал уведомления о сделках тем самым голосом, что в автопилотах вещает. Быстро убрал, задрало насмерть. Но на посетителей производило неизгладимое впечатление. Мечта ж, бот жужжит, бабло бежит, еще и силиконовая баба бесстрастно докладает о прибылЯх несметных.

Anton, Какие такие "все клиенты локальные"?! Тики идут с сервера, а свечи считаются на каждом клиенте. У меня просто челюсть отвисла, когда я об этом узнал. Кому и на кой нужна эта "база тиков"? Разве что этому дурацкому HFT, а нормальные решения по ним принимать практически невозможно - нужны именно свечи. И при чём тут "порисовать"? Мне вот нужно порядка 12 000 свечей (от 15-минутных до месячных - мелочь я считаю сам), и объём у них не "ужатых десяток мегов", да ещё ноухавно ужатых, а распакованных сотня кило. И никаких графиков! Получать к ним доступ через графики - это даже не "только приключений искать", а Полная Жопа!

nikolz, Лапуль, ежу понятно, что "у Вас нет проблем" - Вы же НИЧЕГО не умеете! Какая, в задницу, могёт быть "помощь" от распальцованного полуграмотного неуча, которому я ещё 16.10.2020 08:43:39 писал: "Учите матчасть"? А 30.10.2020 13:46:16 писал: "Открываем книжицу "Руководство пользователя" от ARQA - так там буквально в названии чёрным по белому: "ИНТЕРПРЕТАТОР языка Lua". VM, да будет Вам известно, это ТОЖЕ интерпретатор! А 31.10.2020 12:35:26 писал: "Может, хватит, господа? Сначала один нёс какую-то клиническую ахинею про "роботов и всякие прочие глупости", да ещё с гнутыми пальцами вроде "вы даже понимаете суть вопроса". Получил щелчок по носу - теперь чего-то шипит про "троллей". Потом второй начал пальцы гнуть на тему API в том же ключе: "По-моему вы ничего не понимаете", да про int-float ("Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соответственно нельзя хранить int64"), да про "не надо путать стек процессора и стек Lua - это разные стеки. Вам бы документацию почитать и хорошенько разобраться в луа", да про "выучи английский", да про "умение читать документацию и гуглить", после чего вообще забился в истерике. Потом третий понёс пургу про "монстров фондового рынка", и тоже с гнутыми пальцами: "Вы еще далеки от понимания реальности фондовых рынков" и совсем уж клинический бред с ещё большей распальцовкой: "вот некоторые из аксиом, которые надо усвоить и научится программировать", затем бред про мантиссы ("для справки: Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что  позволяет точно отобразить лишь 16 разрядное десятичное целое число, а не  18 квинтиллионов, как наивно полагает Владимир"), затем про "это VM а не интерпретатор", и тоже с истерикой: " в языках и виртуальных машинах вы ноль без палочки"... я прям утомился этому неучу по носу щёлкать!" Если забыли, то "третий" - это как раз Вы, лапуль.

В общем, надоело листать: Последнее, что попалось на глаза из моих обращений к Вам, датировано 04.08.2021 13:57:04: "Что, сегодня в Кащенко день открытых дверей?". Да 16.08.2021 12:47:16: "Лапуль, ну хватит напрашиваться! Ну ведь растопчу и проглочу, как это уже не раз бывало. У нас просто разные весовые категории".

swerg, О! Ещё один умник нарисовался. Это, по-моему, "второй". Или даже "первый".  

Anton, Я о Квике. У меня никогда не было ни малейших сомнений, что свечи считаются на сервере, но, как мне тут популярно объяснили, считаются они на клиенте из таблицы обезличенных сделок.

Из тиков МОЖНО построить любые агрегаты. Ну так и стройте их НА СЕРВЕРЕ! А на клиента транслируйте уже готовые "агрегаты". И на сеть нагрузка будет намного меньше, и процессоры клиентские не придётся забивать дурацкой работой.

А здесь и спорить нечего: нормальные решения по тикам принимать практически невозможно - нужны именно свечи. Аксиома!  

Я имею ввиду именно свечи стандартных таймфреймов, а не те, которые кроме как самостоятельно не рассчитать.

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

Владимир, хозяин барин. Чет вот вспомнил. Был интересный чел, математик кстати, обнаруживший вырождение распределения в многочастичном фильтре, принявший эффект за имманентное свойство рынка и, что забавно, поднявший на этом неплохо бабла. Где-то в 14 году вышла работа об этом эффекте, доказывающая, что он есть свойство самого фильтра. К сожалению, с челом уже нельзя пообщаться на эту тему по объективной причине, а было бы интересно его мнение теперь услышать. Это я к чему. Все йогурты могут быть полезны, пока горят достаточно далеко от.

Здравствуйте.
Кто может подсказать как идет поток ордеров в таблице обезличенных сделок, например одномоментно  в 10:10:00 прошло 7 продаж (7 строк) 20 контрактов, 18, 15, 10 и 5. Эти 7 строк в ленте отображаются разом или каждая строчка по отдельности только очень быстро?    

Спасибо nikolz. Уточнить, присылают одним блоком,  а время будет  например 10:10:00 и 10:10:03 (разница 3 секунды).  Т.е. ордера  с временем 10:10:03  как бы отношения к предыдущим ордерам с временем 10:10:00 не имеют?  Почему так сделано интересно, просто захотелось или есть какая то техническая сложность в этом.

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

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