Cuberite Forum

Yes, on its own it's not slow, but it causes lock convoys - each such call must lock an additional plugin's critical section. If the plugin is busy, with lots of hooks, this will become costly.

Is the cPlugin::Call function able to parse functions as parameter?

No, it cannot, mainly because functions in Lua are really closures - they take with them the local values of their containing functions and are able to modify those; this cannot be safely ported to another Lua state structure. Consider the following example:

function FnOuter(ParamOuter)
  local VarOuter = 10;
  local FnInner = function(ParamInner)
    local VarInner = VarOuter + 1;  -- It can read FnOuter's local variables
    VarOuter = VarOuter * 3;  -- It can modify them
    local VarInner2 = ParamOuter + 1;  -- It can even read FnOuter's parameters
  end
  SomeOtherFunction(FnInner);  -- Perfeclt valid Lua code, SomeOtherFunction() can call FnInner however it wants
end

(11-25-2013, 12:29 AM)STR_Warrior Wrote: [ -> ]Is the cPlugin::Call function able to parse functions as parameter?

No, you can however pass a function name and a plugin instance, so the other plugin can call the function on your plugin.

(11-25-2013, 04:44 AM)FakeTruth Wrote: [ -> ]No, you can however pass a function name and a plugin instance, so the other plugin can call the function on your plugin.

Yea I know but I hoped you could use a local function as parameter.

I just realized that you can parse a function as a string and then use the loadstring() function to execute it. for example:

------------------------------------------------
--Plugin 1
local Callback = [[
	return type(500)
]]
Plugin:Call("Example", Callback)


------------------------------------------------
--Plugin 2
function Example(Callback)
	local Function = loadstring(Callback)
	if Function then --If the string is loaded correctly then execute it. Otherwise it's a nil value.
		Test = Function()
	end
	print(Test)
end

now Test should be equal to 'number'.

---

Hmm wait now i'm suddenly unsure if it works..

That might work but is pretty much useless. Such a function won't have the upvalues, so it won't see neither the first plugin's globals nor the locals. Consider this example:

-- Plugin 1:
function CallMe() ... end
g_UseMe = 1;
local SomeVar = 2;

local Callback = [[
  g_UseMe = 2;
  SomeVar = 3;
  CallMe();
]]
Plugin2:Call("Executor", Callback);
-- The call has failed inside Plugin2, but that doesn't propagate here
-- However, g_UseMe is still 1, SomeVar is still 2 and CallMe() hasn't been called.


-- Plugin 2:
function Executor(Callback)
  local Function = loadstring(Callback);
  Function();  -- will set Plugin2's globals g_UseMe to 2 and SomeVar to 3 and then fail with message "CallMe not defined"
end;

---

I'm not sure now whether Plugin2 will fail on the actual execution, or if the loadstring() will already complain about the undefined function. But the end result is the same - the callback just cannot access Plugin1's data in any way.

Yea I posted it and then suddenly I was like: "Wait... It's nog going to work isn't it..."