библиотека lua_share (обмен данными между скриптами lua) (Страница 3 из 6)

Можете на словах описать как queue обеспечивает синхронизацию доступа к некоему объекту данных? Схема должна содержать 2 действия скрипта - взять объект эксклюзивно, отпустить.

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

Я пока не понимаю как это возможно, но уверен, что в любом случае явные методы get_exclusive (блокирующий) и free для произвольного объекта общей памяти были бы удобней. Так есть там мьютекс под объектом или нет?

"отдельный экзешник" нужен только для межпроцессного взаимодействия: когда вы шарите данные между несколькими разными квиками. если вам нужен общий доступ к объектам внутри одного квика (но из разных скриптов) то он не нужен, можно его не запускать. в самом квике тоже есть общее хранилище в котором загружен тот же lua_share_boot.lua

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

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

get()/free() хуже, потому что это  тяжело контролировать. что-нибудь где-нибудь не отпустили, или отпустили не в том порядке - и готово: threadlock. вы же не переживаете, что lua за вас память аллоцирует и освобождает. тут то же самое.

пример testfunc - из скрипта сервера lua_share_server.lua, не lua_share_boot.lua. В нем и методов RPC нет, они тоже в скрипте сервера. Неясно как этот RPC осуществить без сервера. Как минимум надо описать, что именно нужно перенести в lua_share_boot.lua. И вы предлагали этот вариант как синхронизацию. Так все же если testfunc будет в  lua_share_boot.lua, то ее вызовы будут выстраиваться в очередь с ожиданием?

И все же да, логику обрабоки лучше не пихать в boot. Второй ваш пример - queues. Но и здесь в лучшем случае нужно будет всю логику обработки вложить в эти метаметоды, в boot. Тоже не хорошо. По мне так гораздо логичнее добавить поддержку управляемого мьютекса в объекте. Это стандарт многопоточного программирования де факто. Спасибо конечно за заботу о дедлоках, но такими драконовскими ограничениями.. ) нет уж, это через чур. Если все общие данные в одном объекте, то риск дедлоков минимален. И я думаю вы лукавите, говоря, что вышеописанное хоть как-то сравнимо по удобству с get()/free(). Ну не может же у нас быть НАСТОЛЬКО разная логика ) Да и реализовать это должно быть просто. Кто захочет - будет использовать. Кто боится - нет. Может добавите?

Так все же, если testfunc будет в  lua_share_boot.lua, то ее вызовы будут выстраиваться в очередь с ожиданием?

Я довольно наивно добавил в queues ф-цию 

function test(a)
        message(a..' started')
        sleep(5000)
        message(a..' ended')
    end

Планировал вызвать
local queues = sh.GetNameSpace("queues")
queues.test('a')

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

смотрите примеры. они все работают.

"test_name_space" нет, потому что GetIPCNameSpace() создает такой неймспейс (таблицу), если ее нет, или использует существующую, если она уже есть: создана при загрузке lua_share_boot.lua, или позже. такой механизм нужен для того, чтобы кастомизировать поведение таблицы при помощи метаметодов, подробнее про это можно почитать в справке lua: [url]https://www.lua.org/manual/5.3/manual.html#2.4[/url]

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

Итак, у меня не сервер, а ф-ция test в boot.

local sh = require "lua_share"
local ns = sh.GetNameSpace("test_name_space")
ns('test','a')

Выдает attempt to call a table value (local 'ns'). Вот и спрашиваю, как вызывать. Аналогия с IPC сервера не проходит. А мы здесь сегодня только про синхронизацию потоков скриптов внутри одного квика и без сервера.

Что-то мне подсказывает, что вы скажете добавлять lua_share_server.lua как скрипт в квик, запускать его, и именно его поток, а не потоки тех скриптов, будет выполнять ф-цию. Что не правильно, т.к. он один, а ф-ций много. Синхронизовать надо per-function, а не 1 поток на все функции\объекты. С классическим мьютексом потоки макросов бы сами исполняли код. С блокировкой per-mutex (объект)

ок, тогда возвращаемся к примеру queue. Почему нельзя добавить в него такую ф-цию test и вызывать ее атомарно так же, как вызываются метаметоды? Какие метаметоды помимо index,newindex доступны для реализации в таблицах boot, чтобы они вызывались атомарно? Можно ли дать возможность произвольно добавлять им ф-ции и чтобы они были доступны в скрпитах?

А, ну собственно это развитие предыдущего вопроса. Это было бы queue:test("a"). Значит этого пока нет, но не ясно, что же есть помимо index,newindex. Для реализации здесь имитации мьютекса надо 2 метода, соответствующих get и free. Неужто только index,newindex можно задействовать? И имитация будет, как я понимаю, циклом sleep в get, пока уже взят.

Я знаю, какие бывают в lua. Спросил, какие из них поддерживаются библиотекой для атомарного исполнения после взятия их как GetNameSpace. Мы выяснили, что __call с передачей имени внутреннего метода и параметров - не работает. а __index работает.. Тогда какие метаметоды работают и почему только они?

вот, объект типа NameSpace конструируется без обработчика __call:
[url]https://github.com/untoxa/lua_share/blob/master/lua_share_main.pas#L278[/url]

а объект типа IPCNameSpace с обработчиком __call:
[url]https://github.com/untoxa/lua_share/blob/master/lua_share_main.pas#L288[/url]

надо просто дописать имплементацию call для случая NameSpace. но ns("test", "a") не очень красиво, все же ns:test("a") гораздо круче.

нет, нельзя, потому что:

    local ns = sh.GetNameSpace("my_fancy_object")
    local method = ns["my_fancy_method"]
    -- some code here
    -- ...
    local result = method("a", "b", "c")

в смысле механизма исполнения это ничем не отличается от:

    local ns = sh.GetNameSpace("my_fancy_object")
    local result = ns.my_fancy_method("a", "b", "c")

и еще нужно не забывать, что возможно такое:

    local ns = sh.GetNameSpace("my_fancy_object")
    local result = ns.my_subtable.my_other_subtable.my_fancy_method("a", "b", "c")

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

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

можно, как предлагалось много ранее тут, сделать на очередях.