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

Спасибо. Я тут пока обнаружил небольшой inconsistency.
local ns = sh.GetNameSpace("test_name_space")
val = ns:DeepCopy() -- nil
ns["hello"] = nil
val = ns:DeepCopy() -- {}
Было бы хорошо, чтобы всегда пустой NameSpace как nil возвращался, т.к. иногда нужно делать DeepCopy() в очень частом цикле (sleep(1)) и 99.9% времени он пуст. И чтобы не плодить в garbage пустые таблицы.

Можно унифицировать __call для IPC как говорили? Сейчас вот такая реализация гасит сервер при ns('pop'), наверно ищет глобальную. Не знаю, зачем кому-то нужно именно глобальную запускать, когда можно сразу определить ее в каком-то неймспейсе. Ну если нужно, то для глобальных особый неймспейс globals..

__default_namespace_metatable = {
    __newindex = function(self, key, value)
        self.__data[key] = value
    end,
    __index = function(self, key)
        return self.__data[key]
    end,
    __call = function(self, f, ...)
        if f=='get' then return self.__data end
        if f=='pop' then
            local data = self.__data
            if data~=nil and next(data) then 
                self.__data = {}
            else data = nil
            end
            return data
        end
        return self[f](...)
    end
}

И насчет итерирования, о котором вы говорили. Вы предполагали осуществлять блокирование неймспейса на все его итерирование? Иначе это не корректно, он может меняться. Сейчас можно просто взять DeepCopy и по ней итерировать.

..Обнаружил проблему. Как минимум DeepCopy() в IPC в новой сборке работает на порядок медленнее. А может и остальное. С чем это связано? Просто меняю обратно 2 dll - получаю предыдущую скорость. Может сборка без оптимизаций?

нет, не предполагал. если вам нужна блокировка - итерируйте копию.

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

Просто не видно практической необходимости итерировать без блокирования. Этак она может перестроиться так, что даже повторно элементы проитерируются.. ) Ладно, не важно, это я к слову.

А вот такой метод get в __call будет работать по скорости примерно одинаково с DeepCopy?

Выше по поводу __call в IPC и кусок кода метатаблицы для неймспейса. Вызов ns('get'), должен работать аналогично DeepCopy

Хорошо. Добавьте пожалуйста поддержку __call в неймспейсах для IPC. Проксирование как в не-IPC.

Собрал, проверю. И добавил на всякий случай ключ оптимизации -O3. Есть какие-то причины этого не делать?

И нашел, что же тормозит. Это просто sleep(1). Вот сейчас стабильно этот код в квике работает 15.4 сек, а не 1 сек. Но днем с этим проблем не было. Не знаете, что может быть? Причем я пробовал и квиковский sleep и сокетовый, результат одинаков. Причем он такой же и для sleep(10).

local sleep=sleep
for i=0,1000 do
    sleep(1)
end

..после нескольких перезапусков квика сейчас 1.5-1.6с. Не пойму от чего зависит.

Вот, похоже эта проблема. Как исправить видимо на уровне ОС,чтобы не было переключения какого-то
[url]https://stackoverflow.com/questions/23258650/sleep1-and-sdl-delay1-takes-15-ms[/url]

И все это для реализации RPC вызова в другом макросе\квике. Вы говорили только через опрос со sleep можно?
Может еще как-то можно? Sleep(0) приводит к видимой загрузке в простое, а Sleep(15) - много. timeBeginPeriod(1) не сильно портит жизнь ОС\батарее и т.п.?

не работает в последних сборках Windows 10 на глобальном уровне. Надо как-то вызывать это из/для самого процессса.
[url]https://habr.com/ru/post/522212/[/url]
У меня все утилиты показывают текущее разрешение 1мс. А Sleep(1) в квике все равно работает 15.5мс. Но так и не понятно, как он иногда переходит на 1.5мс.
Интересно, если бы такая ф-ция появилась в lua_share.dll для вызова, это работало бы.. )

Спасибо! Вот и моя первая dll для квика. Кажется теперь понимаю, почему вы выбираете паскаль для этого )

я не проверяю, существует объект для вызова или нет. проглатывать ошибки неправильно.

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

то есть не нужно для глобальных функций делать прокси из таблицы с метаметодом __call().

а раз так, то непонятно: что создавать? и почему именно это?

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

не совсем понял что вы имеете в виду в двух последних строках, возможно что-то напутали. так вот:

ns["key"] = "value"

однозначно определяет, что вы хотите присвоить ключу "key" значение "value" в некой таблице. если таблицы нет, то мы ее создаем.

когда мы делаем ns("param") и ns у нас не существует, то что нам создать, таблицу? а у этой таблицы будет метаметод __call()? с чего бы? а если boot удалить?

кроме того, как я сказал, ns не обязательно должна быть таблицей. может быть глобальной функцией. тогда ns("param") можно сделать, а ns["key"] = "value" - нельзя (ну или можно, если функции присвоить метатаблицу с метаметодами __index и __newindex, но это из разряда курьезов).

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

я не считаю, что __call это мегаполезно и нужно использовать это повсеместно.

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

да, можно сослаться на глобальную функцию. да, не описано, потому что я изменения в поведении __call не описывал в доке.