Кривые шибки в QLua

еще у меня глупый вопрос - с функция и c closure - это одно и тоже?

 1. Категорические заявления высказывают обычно дилетанты.

 2. Вы пропустили в первом же комментарии аж восемь пунктов совершенно конкретного кода на C++ демонстрирующего как правильно модифицировать исходники Lua для многопоточного использования.  

 3. Вы, похоже (заметьте   , не утверждаю что точно), не поняли, что после моего комментария разработчики QUIK исправили глобальную ошибки синхронизации в QLua и, что характерно   , сразу после этого сменили номер версии QUIK c 8..  на 9...

 4. Давать советы не видя вашего кода и не имея на это время я не способен.

1.   Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато   ), мог ее исправить.  Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.
2. Вы. похоже, не поняли, что у разработчика QUIK не принято признавать свои ошибки (если они это как-то могут скрыть) и благодарить пользователей за найденные ими баги.
3.   Да.

я собрал тест, который в двух потоках вызывает quik lua функцию sleep на 10 секунд, два потока работают с одним и тем же lua_State, и в этом конкретном случае, потоки отрабатывают параллельно.
одновременно вызывают sleep, одновременно возвращаются из неё.
нет никакой синхронизации/блокировки.

дальше я понял, что сделать тест с lua_lock невозможно, тк lua_lock - просто макрос, и из своей библиотеки "родной" quik lua lua_lock я вызвать никак не смогу.
и другие разработчики - тоже.

вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.

Подсказали бы мне лучше, что такое поле COMMENT при отправке транзакции. Я туда зашарашил дубль её айдишки, надеясь хотя бы по нему идентифицировать сделку, пришедшую по OnTrade, но там я увидел только поле комментария по кличке brokerref, а туда запихивают мой код клиента. А тот комментарий, который я сам давал, где-то из OnTrade вытащить можно?

а вы всё-таки любите опираться на свои гипотезы и делать по ним выводы, интересный вы тип в этом плане :)
нет, интерес не праздный. робот реализован, но в нём есть и проблема, которую я не понимал, связанная "возможно" (да) с блокировками природа которых мне была не ясна.

я предполагаю, что мой тест провалился, потому что обрамление в lock/unlock происходит только для вызовов из lua байткода. а я вызывал sleep через pcall в своей c функции. в этом случае обрамления не происходит. тогда я попробовал даже дополнительный способ: вставил вызов функции sleep внутрь новой lua функции m_sleep, чтобы получить задействовать VM, но и тут ожидаемого "обрамления" не произошло.
возможно там где-то есть и хитрые проверки, чтобы не получалось так, что мы из C функции вызываем из неё другую C функцию, та вызывает lua функцию и мы получаем блокировку.

потом я переделал main на Lua, тест стал выглядеть так
main (lua) -> _main© [создание двух потоков] -> thread © -> m_sleep (lua) -> sleep(10000) (lua)
но оба потока завершаются через 10 секунд одновременно.

 Из того, что написано, можно понять, что ваши клиентские потоки запущенные на С++ кодах используют (под синхронизацией) общий lua_State, выполняя фрагменты Lua-кода. Тем самым эти потоки вмешиваются в существующую схему работы QLua, предполагающую использование QLua-кода только в потоке main и в основном потоке обработки колбеков. Без кода не понять что у вас делается, но вариант близкий к тому что у вас есть, но минимизирующий вмешательство в схему работы QLua мог бы быть следующим (опять гипотеза ). Между потоком main  и клиентскими потоками создаются (для каждого), очередь на прием и очередь на передачу. Взаимодействие потока main и клиентских потоков происходит через такие очереди (синхронизируемые). Поток main обслуживает клиентские потоки, взаимодействуя с QUIK. При этом обеспечиваются условия для параллелизма работы с клиентами и нет вмешательства клиентских потоков в схему работы QLua.

Если вы линкуетесь с lua54.dll, входящим в состав QUIK, то все вызовы у вас идут именно в него. И так и следует делать.
Если же вы к своей dll подшиваете собственный Lua-runtime - ну тогда ССЗБ, как говорится.

swerg, да, линкуюсь с квиком, конечно. речь о lua_lock/lua_unlock, это просто макросы в заголовочных файлах, которые доступны нам только из чистого, не квикового lua и в dll наружу не торчат.

TGB, мне тоже понравилось как и что он писал, ретроспективно. в то время я, видимо, редко посещал форум, не заинтересовался особо этим разговором или не понял.
вот я ещё полазил по исходникам, если интересно. нашел, что если из c-функции вызывать что-то через p_call, блокировка сначала вешается, как я и говорил выше, но потом всё снова приходит в метод luaD_precall, где она снова снимается. так уж реализовано странненько.
другими словами, из lua_pcallK путь всё равно ведёт к luaD_precall.
и из c-функции похоже нереально увидеть блокировку.
можно ещё как-то попробовать поискать-поотделять C-функции QLua от Lua функций в qlua.dll. потому что для lua функций блокировка сниматься не будет в luaD_precall.
не знаю правда сколько в этом пользы, но любопытно. скорее всего там всё сделано через C-функции, я бы делал так.

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

большой вопрос, насколько велика моя степень "вмешательства в логику quik/lua", и что и как может портиться здесь, возможно я недооценил этот момент.
и да, технология у меня используется пока не в полную силу, по факту там лишь 1 дополнительный к main поток чаще всего, я планировал сделать 2-3-4, на каждый счёт отдельно, то есть они и сейчас могут запускаться в ответ на приход нового "клиента"-робота, но у правительства оказались другие планы и торговля на америке и нашей фонде стала в феврале на долгое время неактуальной.
некоторое время я гонял два дополнительных потока, один из которых был просто для получения отдельной информации, но потом для надёжности реальных денежных торгов оставил только 1.
информация из второго мне пока не нужна, тк фонда хоть и торгуется, но это пока не интересно.
возможно если бы я стал расширять потоки, я бы сталкивался с ошибками и стал бы их решать, а так - работает и не падает, хоть main и клиент крутятся в двух разных потоках.

Alexey Danin, возможно, это как-то поможет: #143

байткод не причем,
-----------------
/*
** macros that are executed whenever program enters the Lua core
** ('lua_lock') and leaves the core ('lua_unlock')
*/
#if !defined(lua_lock)
#define lua_lock(L)     ((void) 0)
#define lua_unlock(L)   ((void) 0)
#endif
-----------------------------------------
/*** макросы, которые выполняются всякий раз, когда программа входит в ядро Lua
** ('lua_lock') и оставляет ядро ('lua_unlock')
*/
#если !определено(lua_lock)
#определить lua_lock(L) ((void) 0)
#определить lua_unlock(L) ((недействительный) 0)
#конечный код
-----------------------
таким образом, это макросы для ядра VMLua и они определяются на стадии сборки VMLua.
Если разработчики их определили, то они есть иначе это пустышки.
=================
при вызове через pcall
эти макросы тоже работают если их определили:
===========

LUA_API int lua_pcallk (lua_State *L, int nargs, int nresults, int errfunc,
                       lua_KContext ctx, lua_KFunction k) {
 struct CallS c;
 int status;
 ptrdiff_t func;
 lua_lock(L);
 api_check(L, k == NULL || !isLua(L->ci),
   "cannot use continuations inside hooks");
 api_checknelems(L, nargs+1);
 api_check(L, L->status == LUA_OK, "cannot do calls on non-normal thread");
 checkresults(L, nargs, nresults);
 if (errfunc == 0)
   func = 0;
 else {
   StkId o = index2addr(L, errfunc);
   api_checkstackindex(L, errfunc, o);
   func = savestack(L, o);
 }
 c.func = L->top - (nargs+1);  /* function to be called */
 if (k == NULL || L->nny > 0) {  /* no continuation or no yieldable? */
   c.nresults = nresults;  /* do a 'conventional' protected call */
   status = luaD_pcall(L, f_call, &c, savestack(L, c.func), func);
 }
 else {  /* prepare continuation (call is already protected by 'resume') */
   CallInfo *ci = L->ci;
   ci->u.c.k = k;  /* save continuation */
   ci->u.c.ctx = ctx;  /* save context */
   /* save information for error recovery */
   ci->extra = savestack(L, c.func);
   ci->u.c.old_errfunc = L->errfunc;
   L->errfunc = func;
   setoah(ci->callstatus, L->allowhook);  /* save value of 'allowhook' */
   ci->callstatus |= CIST_YPCALL;  /* function can do error recovery */
   luaD_call(L, c.func, nresults);  /* do the call */
   ci->callstatus &= ~CIST_YPCALL;
   L->errfunc = ci->u.c.old_errfunc;
   status = LUA_OK;  /* if it is here, there were no errors */
 }
 adjustresults(L, nresults);
 lua_unlock(L);
 return status; }

  Вы, все-таки, покажите разработчикам это:
 И дополнительно:

Спасибо, передали информацию разработчикам.

TGB,
Вы ошибаетесь в главном:
Разработчики библиотеки QLUA не являются разработчиками VMLua, в исходниках которой вы ковыряетесь.
Поэтому все Ваши вопросы про  base_funcs (Lua 5.4.1), не по адресу.
----------------------
Кроме того, нигде в документации к LUA ( не к QLUA) не указано, что VMLua является многопоточной виртуальной машиной.
Более того, проблема многопоточности VMLua неоднократно обсуждалась в интернете и есть много способов ее решения.
====================
Разработчики QLUA тоже сделали несколько потока безопасных функций.
О них указано в документации на QLUA.
=====================
Немного поясню Вам по приведенному вами коду из исходников VMLua.
-----------------
Вы ошибаетесь,
  api_incr_top(L);                                      //  ##### ? используется L без синхронизирующих
это не функция а макрос.
-------------------------
вот его определение:
/* Increments 'L->top', checking for stack overflows */
#define api_incr_top(L) {L->top++; api_check(L, L->top <= L->ci->top, "stack overflow");}
-------------------
т е еще на стадии компиляции вместо  api_incr_top(L);
 будет записано  L->top++;
===================
Кроме того, отсутствие блокировки еще не означает невозможности работы данного фрагмента в  многопоточной системе.
================
Если в потоке производится лишь чтение данных, то синхронизация практически не требуется.
=================
чтобы понять надо ли синхронизировать обращение  к функции
luaO_str2num(s, s2v(L->top));   //  ##### ? используется L без синхронизирующих скобок
надо смотреть, пытается ли какой-либо другой поток изменить данные в момент обращения.
=====================
но повторю сказанное ранее,
никто Вам не обещал что эта функция потока безопасная.
======================
"Спасение утопающих - дело рук самих утопающих"

и еще.
Я это уже указывал ранее на форуме, но для Вас специально повторю.
У колбеков и Main различные локальные стеки.
это именно 'L" которую Вы пытаетесь синхронизировать.
А так как локальные стеки разные, то и синхронизировать их не требуется.
А вот глобальный стек у них один и тот же.
И потоки в QLUA  синхронизируется при обращении к глобальным переменным.
Ранее приводил результаты тестов как и что кого тормозит по этой причине.
---------------------------
Для своего пула потоков я использую неблокирующую синхронизацию.
-----------------------
Относительно того, кто что разрабатывал, Вы тоже ошибаетесь.
--------------------------------------
Поэтому хвалитесь своим, а не завидуйте другим.
--------------------------
У меня например более 20 патентов, а  как с этим у  Вас?

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

был на форуме только один мудак Владимир,
теперь к нему присоединился второй- TGB

  "одна гипотеза" - только у бота бывает. Были какие то сомнения и все-таки это грубый бот   . Это не лечится.

 Ну, возможно я ошибаюсь, и ваша гипотеза больше объясняет   .

Видимо, обратиться от имени организации, приобретающей услуги у ARQA :)

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

Здравствуйте,

Диагностика "can't get message size from net" означает, что в процессе подключения к северу возникли проблемы с передачей пакетов.
Эта же диагностика может возникать в процессе работы программы уже после подключения к серверу, по той же причине.
Диагностика "Вы уже работаете в системе" говорит о том, что в момент авторизации какие-то пакеты были отправлены, затем рабочее место  Quik отключилось не дождавшись ответа от сервера.
Сервер при этом посчитал, что авторизация произошла и продолжает отправлять пакеты какое-то время, но не получая ответ, всё же разрывает соединение.
Всё это поведение позволяет сделать вывод о низком качестве канала связи.
Рекомендуем проверить качество канала связи широким ping в 512 байт в количестве не менее 100 пакетов.
Для проверки качества канала связи в командной строке Windows выполните следующую команду:
ping -l 512 -n 100 193.178.135.25,
где: — 193.178.135.25 – IP-адрес сервера QUIK (Ваш ip-адрес Вы можете посмотреть в терминале QUIK в меню Система / Соединения....)

Для нормальной работы программы требуется соблюдение следующих условий:
— время прохождения сигнала (ping) до сервера QUIK – не более 1 секунды;
— процент потерь пакетов данных при ping – не более 3% (рекомендуется не более 1%).

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

Здравствуйте!
Требования к каналам связи сильно изменились с тех пор, как Вы были "сисадмином" у провайдера, Владимир.
Если качать терабайтную базу через модем 30-50 к или через оптику с хорошим роутером, то Вы никак не заметите потери одного или пятидесяти пакетов, потому как они встанут в очередь и следом будут закачаны.
В то же время, если в шифрованном соединении, коим является соединение между клиентом и сервером Quik, пропадает один - три пакета, то соединение ломается, т.к. оно не соответствует требованиям Quik к каналу.
Странно, что Вы как "сисадмин" интернет-провайдера не знаете столь элементарных вещей об ЛВС.
Более странно, что вместо просьб специалиста Quik вы вступаете в полемику и применяете весьма провокативную лексику.
Форум, это публичное место, всё же. Помимо Вас, Ваши слова видны участникам форума.

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