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

Ага, и нужно на каждую ф-цию создавать свой скрипт-считалку, который будет всегда запущен в квике. Именно для ее исполнения в одном потоке. С паковкой\распаковкой всех данных от скриптов-заказчиков. Это намного менее удобно, чем заниматься обработкой самим скриптам в их среде и потоке. Да и нет такой единой ф-ции обработки, каждый макрос делает обработку общих данных по своему. Логику из них выносить не надо, каждый макрос- вещь в себе. Надо только обеспечить им монопольный доступ к объекту общей памяти на нужное им время. Для этого даже не требуется многопоточной машины в библиотеке. Пусть есть 10 макросов, это 11 потоков (+ основной, колбековый) и пусть даже код boot исполняется однопоточно. Мьютексы доступа к объекту должны быть не в lua машине а в dll, на подступах потоков макросов к lua машине.

А в цепочке обращений макроса к dll, к конкретному объекту, должно быть место, исполняемое в потоке макроса и куда можно встроить нормальный mutex, сериализующий эти потоки.

если в качестве разделяемого хранилища используется одна общая lua-машина, как в библиотеке lua_share, данное решение невозможно.

Что значит «не поддерживаются»?! ) А вам, собственно, какие нужны?

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

То есть, в некотором смысле, не только все метаметоды поддерживаются, но и к тому же дважды. Вы сделать-то что хотите?

Вы, вообще, понимаете как метаметоды работают? Не важно сколько по-умолчанию реализовано в dll. Те, что не реализованы вы дописываете на lua сами. Весь код, что имеется в lua_share выполняется эксклюзивно. В контексте разных тредов, но не более чем в одном треде в каждый момент времени.

Если вы в boot определите __mod() то и действовать он тоже будет внутри общей lua-машины. Например, если вы напишете подобное выражение в коде инициализации, либо используете это в другом метаметоде, том же __index().

Нет, можно, конечно, по-умолчанию проксировать вызовы всех метаметодов без разбора, но по-моему такая хрень получится…

через index/newindex. пишете в таблицу данные в какой-нибудь синтетический ключ, скажем, "__mod", на той стороне в __newindex() делаете self % <что-там нужно>, в __mod() на той стороне определяете, что такое "%". можете на этой стороне так же переопределить __mod() чтобы он делал что-то вроде self["__mod"] = 2 и возвращал результат. тогда получится проброс вызова.

просто тупо пробрасывать все подряд лишено всякого смысла. как по-вашему должен пробрасываться вызов __gc() ?!

На что вы ответили "все".
По возможности нужно, чтобы проксирование подхватывало все, которые определены в boot.

__gc() - особый случай. Это не из области функционала объекта, а про управление его жизнью. С т.з. функций прокси по смыслу и есть тот самый объект в общей памяти. Так что смысла в проксировании методов из boot гораздо больше, чем в не проксировании.  Что значит оставить пользователю, если вы не предоставляете пользователю альтернативы горожению протокола RPC в оператор [], единственно доступный? Оставьте пользователю выбор какие метаметоды проксировать, какие нет - тогда да. А если не возможно - проксируйте по умолчанию то, что задано в boot. Переопределить метаметоды в прокси пользователь как раз сможет при желании. А проксировать - нет. Либо вы не сказали как.

__call для всех логичнее проксирвоать, а для вызова глобальных ф-ций определить особый namespace "globals" и в нем его переопределить.

И еще, стоит рассмотреть переход на патченную машину с поддержкой многопоточности. Монстр квиковская или нет, но это у нас среда исполнения де-факто. И она нормально работает в потоках main и колбеков. Но может вы лучшую найдете.
Потому что без этого как можно было всерьез предлагать переносить обработку в boot и RPC, если эти методы будут блокирвоать всю общую память? В многопоточной сериализация потоков будет уже на уровне объектов. Ну и, видимо, если использовать квиковскую машину, то в boot будут доступны и все ф-ции квика.

да

нет

ну пусть arqa technologies и делает. функции доступны не будут, чтобы были - quik должен сам инициализировать lua-машину в момент ее создания, а это невозможно из сторонней dll.

в общем, резюме такое: поддержать call(), поддержать _pairs(), по возможности сделать динамическое проксирование функций: ns.other_table:method(args) - это интересная задача. когда у меня появится возможность этим заниматься я доделаю.

напоминаю, что lua_share это бесплатная open-source mit-licenced библиотека. если вам что-то не нравится, или вы хотите что-то доделать в ней быстрее - всегда можно форкнуть и сделать из этого форка все что угодно самостоятельно.

вот, я делал такой proof-of-concept для "многопоточной" lua-машины quik: [url]https://github.com/untoxa/lua_threads[/url] можете попробовать использовать это. но, повторюсь: идея - говно, несмотря на то, что прототип более-менее работает.