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

Страницы: Пред. 1 2 3 4 5 6 След.
RSS
Кривые шибки в QLua
 
Цитата
Павел Bosco написал:
вы как-то анализировали устройство Qlua? Или это догадки?
  Почитайте комментарии начиная с https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696
 
Цитата
TGB написал:
Цитата
Павел Bosco написал:
вы как-то анализировали устройство Qlua? Или это догадки?
Почитайте комментарии начиная с  https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696
почитал пару листов, у вас там очень обобщающие рассуждения "похоже, что" "скорее всего", основанные на ваших собственных наблюдениях и тестах.



Тем не менее спрошу, нашлось ли подтверждение (из кода или от поддержки), что lua_lock/unlock реально что-то делает в QLua? Если да, то получается что если у меня есть в c closure "main" обычный windows Sleep, мне его лучше обрамить qlua_unlock / qlua_lock?
А соответственно вместо моей собственной CriticalSection лучше использовать встроенный qlua_lock/qlua_unlock?
Поясню - у меня в main крутится диспетчер входящих клиентских соединений, создающий дополнительные потоки для каждого клиента. Все клиенты работают через единый lua_State, обрамлённый CriticalSection.
Всё работает, не падает, но в целях стабильности и скорости, мне приходится держать Quik свёрнутым. Потому что время сервера начинает дико отставать при отрисовке графики. И я подозреваю (да, обобщение, увы) что дело в каких-то блокировках, которые, возможно создаёт мой скрипт, делая что-тоо не так. У меня нет доказательств что что-то не так делает quik, а просто рассуждать обобщающе на эту тему неохота. Самый быстрый способ что-то исправить - это дать разработчику короткий, но 100% действенный тесткейс повторения ошибки.
 
еще у меня глупый вопрос - с функция и c closure - это одно и тоже?
 
написал себе заметочку, повторю тут, как можно проверить блокировку (а она сейчас с нами, в этой комнате?)
1) первый тест, который в мейн будет порождать два потока, писать "я в потоке а", делать  lua_lock, windows Sleep на 10 секунд,  "я вышел из паузы в потоке а", lua_unlock
и тоже самое в потоке б.
2) второй тест - сделать тоже самое, но без lua_lock сделать qlua sleep, декларируется что там используется блокировка?
3) если я правильно понимаю, то блокировка будет в обоих случаях, то есть два потока отработают последовательно, а не параллельно

если моё понимание в 3) верно, то все Sleep и WaitForSingleObject для main надо обрамлять lua_unlock перед и lua_lock после.
 
Цитата
Павел Bosco написал:
почитал пару листов, у вас там очень обобщающие рассуждения "похоже, что" "скорее всего", основанные на ваших собственных наблюдениях и тестах.
 1. Категорические заявления высказывают обычно дилетанты.

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

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

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

возможно всё-таки я не о том пишу, для этого хотелось бы понять, c-closure и c функция это одно и тоже или нет. или другими словами, что имеется в виду под с функцией.
 
1.
Цитата
Павел Bosco написал:
есть реальный факт что ваши пожелания заставили разработчиков что-то сделать и сменить версию?
  Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато  :smile: ), мог ее исправить.  Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.
2. Вы. похоже, не поняли, что у разработчика QUIK не принято признавать свои ошибки (если они это как-то могут скрыть) и благодарить пользователей за найденные ими баги.
3.
Цитата
Павел Bosco написал:
хотелось бы понять, c-closure и c функция это одно и тоже или нет. или другими словами, что имеется в виду под с функцией.
  Да.
 
Цитата
TGB написал:
Цитата Павел Bosco  написал:
хотелось бы понять, c-closure и c функция это одно и тоже или нет. или другими словами, что имеется в виду под с функцией.  
Да.
Уточнение: ответ дан относительно синхронизации при многопоточном использовании Lua.  Чем отличаются замыкания от обычных функций можно прочесть в интернете.
 
Цитата
TGB написал:
Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато  :: ), мог ее исправить.  Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.

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

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

вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
 
Нафига вам всё это нужно, господа? Я потратил недели две, чтобы вынести всё, что можно, в поток main и уже практически забыл про вылеты скрипта или отвисания Квика. Не говоря уже о том, что я буквально с первого же дня постулировал: никаких библиотек, никаких других языков - скрипт должен работать на любой версии Квика и любой версии языка. И никаких стаканов, никаких свечей, никаких графиков, никаких сокетов. А все вопросы синхронизации/блокировки выполняются самим скриптом, у которого для этого заведены соответствующие стеки и флаги. Ведь наша задача - получить рабочую версию торговой программы, а не вести бесконечную борьбу с глюками всех мастей и размеров.
 
Подсказали бы мне лучше, что такое поле COMMENT при отправке транзакции. Я туда зашарашил дубль её айдишки, надеясь хотя бы по нему идентифицировать сделку, пришедшую по OnTrade, но там я увидел только поле комментария по кличке brokerref, а туда запихивают мой код клиента. А тот комментарий, который я сам давал, где-то из OnTrade вытащить можно?
 
1.
Цитата
Владимир написал:
Нафига вам всё это нужно, господа? Я потратил недели две, чтобы вынести всё, что можно, в поток main и уже практически забыл про вылеты скрипта или отвисания Квика.
   Вы забыли про вылеты и отвисания потому, что усилиями разработчика QUIK и его пользователями было вычищено много глюков (в том числе и ошибок снхронизации). Иначе вылетали бы и отвисали до сих пор.
   Я хорошо знаю как строить устойчиво работающие программные системы, функционирующие в неустойчивых средах (в том числе аппаратных), но когда вижу "корявую" среду, которую можно улучшить, то почему бы это не делать?

2.
Цитата
Павел Bosco написал:
вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
   У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу  :smile: , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.
 
Цитата
TGB написал
2.  
Цитата
Павел Bosco написал:
вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу  :: , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.

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

я предполагаю, что мой тест провалился, потому что обрамление в 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 секунд одновременно.
 
TGB, У меня полностью обратное впечатление: помню свой первый шок, когда я узнал, что ИНТЕРПРЕТИРУЕМЫЙ код способен подвесить Квик. Вылет скрипта (при НОРМАЛЬНОМ системном софте), по моим представлениям, возможен только при ошибках в коде самого скрипта, но здесь... Ещё один шок - несколько прерываний на одно событие, ещё один - убийство целочисленного типа данных, ещё один - динамическая типизация, из-за которой происходит добрая половина обсуждаемых здесь глюков... я давно уже боюсь новых версий, ибо не видел ещё ни одного исправленного глюка - в т.ч. из числа тех, про которые здесь пишут годами, и до сих пор встречаю всё новые и новые, хотя алгоритмически задача простая до неприличия. Эту среду надо не улучшать, а полностью переписывать набело, с нуля.
 
Цитата
Павел Bosco написал:
Поясню - у меня в main крутится диспетчер входящих клиентских соединений, создающий дополнительные потоки для каждого клиента. Все клиенты работают через единый lua_State, обрамлённый CriticalSection.Всё работает, не падает, но в целях стабильности и скорости, мне приходится держать Quik свёрнутым. Потому что время сервера начинает дико отставать при отрисовке графики. И я подозреваю (да, обобщение, увы) что дело в каких-то блокировках, которые, возможно создаёт мой скрипт, делая что-тоо не так.
 Из того, что написано, можно понять, что ваши клиентские потоки запущенные на С++ кодах используют (под синхронизацией) общий lua_State, выполняя фрагменты Lua-кода. Тем самым эти потоки вмешиваются в существующую схему работы QLua, предполагающую использование QLua-кода только в потоке main и в основном потоке обработки колбеков. Без кода не понять что у вас делается, но вариант близкий к тому что у вас есть, но минимизирующий вмешательство в схему работы QLua мог бы быть следующим (опять гипотеза :smile: ). Между потоком main  и клиентскими потоками создаются (для каждого), очередь на прием и очередь на передачу. Взаимодействие потока main и клиентских потоков происходит через такие очереди (синхронизируемые). Поток main обслуживает клиентские потоки, взаимодействуя с QUIK. При этом обеспечиваются условия для параллелизма работы с клиентами и нет вмешательства клиентских потоков в схему работы QLua.
 
TGB, как-нибудь потихоньку разберусь.
понял о чём вы начинали говорить с Anton еще тут https://forum.quik.ru/messages/forum10/message49035/topic5852/#message49035
вся Lua работает под одной критической секцией, которая разблокируется на время вызова C function.
мой тест был задуман не верно, - мои вызовы идут в обратную сторону, через C function в Lua. я так сделал, потому что у меня и робот так работает.

то есть мне надо смотреть не на luaD_precall, а на lua_pcallk.
и что характерно, в ней таки есть lua_lock на входе, а на выходе - lua_unlock.
то есть c function, которая идёт по pcall (вообще не важно в lua или тоже в с функцию), на время вызова должна бы блокироваться
со слов Антона, там под lock сделан mutex (я ничего такого не проверял). а у меня как раз два O.S. thread конкурентно вызывают lua sleep на 10 секунд.
и конкурентно возвращаются из него.
опять непонятно..
 
Цитата
Павел Bosco написал:
дальше я понял, что сделать тест с lua_lock невозможно, тк lua_lock - просто макрос, и из своей библиотеки "родной" quik lua lua_lock я вызвать никак не смогу.
и другие разработчики - тоже.
Если вы линкуетесь с lua54.dll, входящим в состав QUIK, то все вызовы у вас идут именно в него. И так и следует делать.
Если же вы к своей dll подшиваете собственный Lua-runtime - ну тогда ССЗБ, как говорится.
 
Цитата
Павел Bosco написал:
понял о чём вы начинали говорить с Anton
  Мне жаль, что Anton перестал с какого-то времени выкладывать свои комментарии. Были ситуации когда мы с ним жестко дискутировали и, наверное, я его иногда обижал. Но я всегда считал. что он много делал полезного для улучшение QUIK и для его пользователей.
 
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-функции, я бы делал так.
 
Павел Bosco, видно, что вы хотите разобраться в том, как функционирует QLua. Но я не вижу вашей реакции на мой комментарий:
Цитата
TGB написал:
Из того, что написано, можно понять, что ваши клиентские потоки запущенные на С++ кодах используют (под синхронизацией) общий lua_State, выполняя фрагменты Lua-кода. .....
Что я не понял в вашей схеме обработки клиентских потоков?  Какие у вас есть возражения против предлагаемых мной изменений вашей схемы обработки клиентских потоков?
 
TGB, ну у меня не было запроса к вам на изменение или оценку логики моей программы (вроде бы?). соответственно к чему бы мне реагировать на предложение что-то менять?
да, к lua_State я обращаюсь из разных потоков, используя синхронизацию, всё верно.
не вижу проблем сделать и очередь, решение не плохое. ирония в том, что я с очередями работаю порядка 20 лет, этот шаблон мне мягко говоря знаком.

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

Извиняемся за столь длительную задержку с ответом, к сожалению, нам не удалось ни установить причину описанной в сообщении - https://forum.quik.ru/messages/forum10/message59792/topic5823/#message59792 проблемы, ни воспроизвести. Однако мы зафиксировали всю информацию и продолжим далее разбираться с данной проблемой в рамках Вашего обращения - https://forum.quik.ru/messages/forum10/message64068/topic5823/#message64068 .
Приносим извинения за причиненные неудобства.
 
Alexey Danin, возможно, это как-то поможет: #143
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Alexey Danin , возможно, это как-то поможет:  #143
Благодарим за информацию, примем этот комментарий к сведению при разборе проблемы.
 
Цитата
Павел Bosco написал:
Цитата
TGB написал
2.  
Цитата
Павел Bosco  написал:
вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу  :: , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.

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

я предполагаю, что мой тест провалился, потому что обрамление в 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 секунд одновременно.
байткод не причем,
-----------------
/*
** 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; }
 
Я работаю с потоками в квике даже с пулом потоков
в тестах максимально открывалось 15 потоков.
О тестах уже писал.
В тесте выставлялись заявки и после выставления снимались
по 200 инструментам за 4 часа работы было выставлено и снято 200 тысяч заявок.
Не было ни одной ошибке типа "заявку снять невозможно"
Ни одного зависания.
----------------  
Я это к тому, что Ваши рассуждения лишь доказательство ошибок в вашем софте.  
 
Цитата
Alexey Danin написал:
Извиняемся за столь длительную задержку с ответом, к сожалению, нам не удалось ни установить причину описанной в сообщении -  https://forum.quik.ru/messages/forum10/message59792/topic5823/#message59792  проблемы, ни воспроизвести.
  Вы, все-таки, покажите разработчикам это:
Цитата
TGB написал:
Этот комментарий пишу, в основном,  для разработчика QUIK.
1. При открытии библиотеки base_funcs (Lua 5.4.1), в которой находится tonumber, все ее функции помечаются как С-функции. Это означает, что в программе Lua они выполняются в скобках: lua_unlock(L);    Запуск C-функции;    lua_lock(L);      
 Такие функции могут выполняться параллельно с исполнением  QLua-кода. Однако любые операции с использованием в них L, должны выполняться в синхронизирующих скобках:  lua_lock(L);    Выполнение операций в L;     lua_unlock(L);      
 При просмотре исходника функции tonumber (с учетом вызываемых в ней функций), я обнаружил, что в этой функции есть как минимум один фрагмент с использованием операций в L без синхронизирующих скобок (мои комментарии помечены в исходнике символами #####).
 !!!   lua_stringtonumber вызывается в tonumber:
LUA_API size_t lua_stringtonumber (lua_State *L, const char *s) {
 size_t sz = luaO_str2num(s, s2v(L->top));   //  ##### ? используется L без синхронизирующих скобок
 if (sz != 0)
   api_incr_top(L);                                      //  ##### ? используется L без синхронизирующих скобок
 return sz;
}
    Возможно, что-то я упустил, но пусть это проверит разработчик QUIK.
 И дополнительно:
Цитата
TGB написал:
Не факт, что обнаруженная сложная ошибка (синхронизации) относится только к tonumber. Существующая реализация разработчиком Lua стандартных C-функций Lua (5.4.1) архитектурно не учитывает многопоточность использования Lua. Для выполнения любых операций в таких функциях с элементами, хранящимися в lua_State, надо было сделать доступным только API-C, но этого не сделано.
 
Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить.
 Пусть разработчик QUIK объяснит, в чем я ошибаюсь.
 
Цитата
TGB написал:
Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить.  Пусть разработчик QUIK объяснит, в чем я ошибаюсь.
Спасибо, передали информацию разработчикам.
 
Цитата
Alexey Danin написал:
Цитата TGB написал:Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить.  Пусть разработчик QUIK объяснит, в чем я ошибаюсь.
Спасибо, передали информацию разработчикам.
  Долгое молчание: знак согласия с тем что я написал (дважды)?
 
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 без синхронизирующих скобок
надо смотреть, пытается ли какой-либо другой поток изменить данные в момент обращения.
=====================
но повторю сказанное ранее,
никто Вам не обещал что эта функция потока безопасная.
======================
"Спасение утопающих - дело рук самих утопающих"
 
Цитата
nikolz написал:
Вы ошибаетесь в главном:Разработчики библиотеки QLUA не являются разработчиками VMLua, в исходниках которой вы ковыряетесь.Поэтому все Ваши вопросы про  base_funcs (Lua 5.4.1), не по адресу.
   Похоже, вы ничего никогда не разрабатывали. Нормальный разработчик отвечает за свою разработку независимо от того что он при этом использует. А ненормальный будет рассказывать что у него не работает из того чем он пользуется (например, "кривой" головой). В этом форуме вы пишите лишь бы как то наследить :smile: .
 
Цитата
TGB написал:
Цитата
nikolz написал:
Вы ошибаетесь в главном:Разработчики библиотеки QLUA не являются разработчиками VMLua, в исходниках которой вы ковыряетесь.Поэтому все Ваши вопросы про  base_funcs (Lua 5.4.1), не по адресу.
    Похоже, вы ничего никогда не разрабатывали. Нормальный разработчик отвечает за свою разработку независимо от того что он при этом использует. А ненормальный будет рассказывать что у него не работает из того чем он пользуется (например, "кривой" головой). В этом форуме вы пишите лишь бы как то наследить :: .
и еще.
Я это уже указывал ранее на форуме, но для Вас специально повторю.
У колбеков и Main различные локальные стеки.
это именно 'L" которую Вы пытаетесь синхронизировать.
А так как локальные стеки разные, то и синхронизировать их не требуется.
А вот глобальный стек у них один и тот же.
И потоки в QLUA  синхронизируется при обращении к глобальным переменным.
Ранее приводил результаты тестов как и что кого тормозит по этой причине.
---------------------------
Для своего пула потоков я использую неблокирующую синхронизацию.
-----------------------
Относительно того, кто что разрабатывал, Вы тоже ошибаетесь.
--------------------------------------
Поэтому хвалитесь своим, а не завидуйте другим.
--------------------------
У меня например более 20 патентов, а  как с этим у  Вас?
 
Цитата
nikolz написал:
У меня например более 20 патентов, а  как с этим у  Вас?
   С этого места, пожалуйста поподробнее.
Выложите список своих патентов с их кратким описанием и с указанием всех реквизитов, обеспечивающих  проверку их существования.
 
TGB, Господи, да пусть хоть в три слоя до пупа справками обвешается - это никак не влияет на тот медицинский факт, что он есть неграмотный дурак. :smile:  
 
Цитата
Владимир написал:
он есть неграмотный дурак.  
 Относительно nikolz у меня существовали разные гипотезы (в том числе и то, что это человек), но я все более склоняюсь, что это полу-интеллектуальный бот-спамер  :smile: . Что удивительно так это то, что он иногда, редкими местами, пишет вразумительные вещи. Слава создателю этого бота  :smile: .
 Я бы не стал его комментировать, но он часто выкладывает тексты, вносящие смуту в неокрепшие умы: типа его сентенции в сообщении #181. Конечно, каждый читающий сообщения, наверное, определит сам, где туфта, но, как представляется мне, этот бот постоянно производит информационный мусор (возможно, со злонамеренной целью переполнения базы форума  :smile: ).
 
был на форуме только один мудак Владимир,
теперь к нему присоединился второй- TGB
 
У меня всего одна гипотеза относительно почему они мудаки.
Знаний нет, учиться им уже позно, поэтому пишут чушь .
 
Цитата
nikolz написал:
У меня всего одна гипотеза относительно почему они мудаки.
  "одна гипотеза" - только у бота бывает. Были какие то сомнения и все-таки это грубый бот  :smile: . Это не лечится.
 
TGB, Нет, у меня другая гипотеза: он настолько туп, что искренне считает себя чем-то состоятельным в области программирования. А вот что касается подсознания, то чувствует он всё правильно, и потому после нескольких попыток впарить лохам свои бредни под видом откровений просто закрывает хлебальник и исчезает на несколько дней. После чего снова всплывает примерно с теми же бреднями. Технология "ссы в глаза".
 
Цитата
Владимир написал:
TGB , Нет, у меня другая гипотеза
 Ну, возможно я ошибаюсь, и ваша гипотеза больше объясняет  :smile: .
 
Цитата
TGB
   TGB написал: Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить.  Пусть разработчик QUIK объяснит, в чем я ошибаюсь.
   Alexey Danin  написал:  пасибо, передали информацию разработчикам.
------
 TGB написал:  Долгое молчание: знак согласия с тем что я написал (дважды)?
 У меня вопрос к поддержке (простой, но, скорее всего, риторический).
 У каждого приличного IT-разработчика, как правило, существует в поддержке инструкция по работе с пользователями. Надеюсь что такая есть у ARQA и она не секретная.
 Мне хотелось бы на нее посмотреть.     Как это можно сделать?
 
Видимо, обратиться от имени организации, приобретающей услуги у ARQA :)
 
Ну просто зла не хватает!

Различные глюки Квика, к сожалению, давно стали привычными - то у него какой-то сертификат просрочен (при повторной аутентификации всё волшебным образом становится зашибись), то какой-то message size считать не может, но больше всего достаёт, когда после обрыва связи при попытке законнектиться этот придурок выдаёт "вы уже работаете в системе" и рвёт, падла, связь. Ты что, не видишь, козёл, что связи нет, что именно поэтому я и пытаюсь подключиться? Перезапускаю Квик - пофиг, "вы уже работаете в системе"! Снова выхожу, и через пару-тройку минут успокаивается и нормально входит, теперь я уже "в системе не работаю". Да ещё предупреждает, скотина, что была неудачная попытка аутентификации - это та самая, которую он и оборвал. Как можно ТАКОЕ запрограммировать?
 
Типа нажал кнопку утром, и мечтаем до вечера спать, но  не получилось работать.
------------------------
А у меня получается,
после того как построил провайдера и показал где у него узкое место.
Теперь все тип-топ.
 
nikolz, Лапуль, во-первых, связь не каждый день рвётся. Вернее, во-первых, каким боком здесь вообще провайдер и что ему здесь можно "показать"? А ну, шайбу! :wink:  
 
Цитата
Владимир написал:
Ну просто зла не хватает!

Различные глюки Квика, к сожалению, давно стали привычными - то у него какой-то сертификат просрочен (при повторной аутентификации всё волшебным образом становится зашибись), то какой-то message size считать не может, но больше всего достаёт, когда после обрыва связи при попытке законнектиться этот придурок выдаёт "вы уже работаете в системе" и рвёт, падла, связь. Ты что, не видишь, козёл, что связи нет, что именно поэтому я и пытаюсь подключиться? Перезапускаю Квик - пофиг, "вы уже работаете в системе"! Снова выхожу, и через пару-тройку минут успокаивается и нормально входит, теперь я уже "в системе не работаю". Да ещё предупреждает, скотина, что была неудачная попытка аутентификации - это та самая, которую он и оборвал. Как можно ТАКОЕ запрограммировать?

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

Диагностика "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%).

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

Я понимаю, что "can't get message size from net" означает, что в процессе подключения к северу возникли проблемы с передачей пакетов. Только что включал один из Квиков так трижды получал "can't get data from net", хотя у меня ещё с прошлого тысячелетия стоит оптика, второй Квик на том же компе прекрасно работает, а на другом компе, подключённом через тот же роутер, я сейчас это дело и пишу, а оба Квика в другой комнате работают. Эта ситуация неприятна, но понятна, здесь претензий нет - я говорил именно про "Вы уже работаете в системе", и эта диагностика НЕ МОЖЕТ "говорить о том, что в момент авторизации какие-то пакеты были отправлены, затем рабочее место  Quik отключилось не дождавшись ответа от сервера" - связь рвал именно сервер, причём немедленно после попытки авторизации, а тот факт, что после повторного входа после такой ситуации приходит сообщение о попытке авторизации с такой-то айпишки, говорит о том, что сервер НЕ посчитал, что авторизация произошла и разрывает соединение НЕ по причине проблем со связью.

Я когда-то сам был сисадмином Инет-провайдера, когда ещё клиенты дозванивались через пул телефонов со скоростью порядка 30-50К, но даже тогда проблемы были именно у клиентов, а у меня, сидящего на радиоканале, никаких проблем со связью не было. А уж сейчас... именно на этом "низкого качества канале связи" я качал несколько дней почти терабайтную базу данных - и ничего, прекрасно скачалась.

А чем мой тон диалога недружелюбный? Это же я с Квиком разговаривал. :smile:  
 
Цитата
Владимир написал:
Даниил Волошин, Здравствуйте,


Я когда-то сам был сисадмином Инет-провайдера, когда ещё клиенты дозванивались через пул телефонов со скоростью порядка 30-50К, но даже тогда проблемы были именно у клиентов, а у меня, сидящего на радиоканале, никаких проблем со связью не было. А уж сейчас... именно на этом "низкого качества канале связи" я качал несколько дней почти терабайтную базу данных - и ничего, прекрасно скачалась.

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

Просьба моего коллеги состояла в том, что нужно выполнить наши рекомендации по проверке канала и если не увидите в этих данных причину подобного поведения, то сообщите об этом нам, предоставив результаты тестирования.
Очень важно, чтобы тестирование производилось с указанными ранее параметрами.
От себя добавлю, что если связь через WiFi, то перейдите на кабельное соединение.
 
Vladimir Ivanov, У меня уже много лет нет ни малейших претензий к каналам связи - да, они сильно изменились, но, надеюсь, в лучшую сторону? Связь у меня рвётся не каждый день, используется годами практически ежедневно, и проводить какое-либо её тестирование я не вижу смысла. Очевидно, проблемы в софте. Если "в шифрованном соединении пропадает один - три пакета, то соединение ломается", то софт просто никуда не годится. АДНАЗНАЧНА! Ведь софт тоже, надеюсь, должен меняться в лучшую сторону.

Я не понимаю, какие у Вас претензии к моему стилю - я почти всегда вежлив с собеседниками (что далеко не всегда можно сказать о некоторых из них), и я много лет знаю, что для качественной полемики эффективнее всего работает именно провокативная лексика. По крайней мере, при разговоре со специалистами. За все 30 лет моего пребывания в Инете я никогда не прятался, никогда не имел ника, по которому не было бы очевидно, что я - это я, и не вижу ни единой причины, по которой любые мои посты не должны быть видны участникам форума.

У меня здесь три компа, в один воткнут оптоволоконный кабель, а два других (в том числе тот, который используется для торговли) подключены через WiFi, но на торговом компе, кроме двух Квиков, вообще ничего нет - там просто смешной траффик, а на втором почти всегда идёт какое-то видео из Ютуба. Сейчас все три компа работают, никаких проблем со связью нет, на одном работают два Квика, на втором я пишу это сообщение и слушаю Пионтковского - он тоже подключен через WiFi. Более того, как я сказал ранее, такое поведение НЕ МОЖЕТ быть объяснено некачественной связью, связь разрывает сам сервер, и разрывает её потому, что думает, что происходит вторая попытка авторизации - типа, злоумышленник пытается войти.
Страницы: Пред. 1 2 3 4 5 6 След.
Читают тему
Наверх