Callbacks?

[thephd]

Callbacks?

[ThePhD]

You can replace luaFncPointer cb with one of 2 types: std::function<ReturnType(Arguments...)> OR sol::function. sol::function is the most flexible (can pass it different number of args and stuff, while std::function has a fixed signature).

Code would look like...

lua.set_function("print", [](const char *  y){ std::cout << y << std::endl; });
lua.set_function("getUser", [](int id, sol::function cb)
{
/* ... */
cb( 24, some_ptr, ... ); // whatever you like
/* ... */
 });

Sorry about not having a place this is clear: I gotta pump up the docs to be a LOT more specific with this stuff so that people get the proper guidance.

[ThePhD]

NULL is a macro from the C standard that, in C++, usually resolves to 0. This will push an integer, which isn't what you want: try doing cb( sol::nil, "THE USER" ) or cb( nullptr, "THE USER" )

[EToreo]

This is great! But how do I return null or empty to the first argument of the lua callback?

lua.set_function("getUser", [](int id, sol::function cb)
{
    cb(NULL, "THE USER");
});

[EToreo]

Thank you!

[EToreo]

Will sol::function take ellipsis?

[ThePhD]

No, it won't take ellipses, but you can feed it as many arguments as you like.

[EToreo]

@ThePhD Thanks for all your help. I'm really enjoying your library. I have one more big question for you...

I am trying to call a sol::function callback from an asynchronous thread. My lua.set_function("getUser" [&](int id, sol::function gotUserDataCb {...}) has to asynchronously ask nodejs for some information, and in that response (using uv_queue_work, uv_after_work_cb, etc) I need to execute gotUserDataCb passing the data I received on the worker thread. My issue is: that causes a segmentation fault. I think this is because the sol::state goes out of scope long before getUser tries to respond.

Do you have any tips here? Am I on the correct track, should I try to find a way to keep the sol::state from going out of scope (make it a pointer and manually delete it)?

[ThePhD]

You need to shift the lifetime of the sol::state you set that function on. Move its scope up your application's stack a bit, so it will last. Make it a shared_ptr if you really need to keep it alive. There's no reason to manually track the lieftime with those kind of tools.

[EToreo]

I took your suggestion and made it a shared pointer (moving the sol::state up in scope can't be done in my case). I am now getting an exception thrown from sol->script:

terminate called after throwing an instance of 'sol::error'
what(): lua: error: attempt to call a nil value

(The lua script is the same as the original posting in this issue.)

[ThePhD]

That could happen from a number of things. I have no idea what would be the problem, and I'm not sure I can reason about how your entire application stack sets up things.

[EToreo]

Fair enough. I think the problem is that the actually sol::function gotUserDataCb is being called after lua->script is done executing. Is there a lua lock offered by sol? I have head mention of locking and unlocking in other discussions about lua hooks.

[EToreo]

@ThePhD hey, I just wanted to say thank you. I got where I needed to go with the help of your library and advice. To solve the last problem I was having I had to implement lua_lock and lua_unlock in a custom lua build and bind that custom built lua library and header files into my program along with sol2. I now have a fully functioning bridge between nodejs and lua.

[ThePhD]

Nice! If you think there's a nice way to do lua_lock that can be added to sol2, feel free to open up another Bikeshed issue.

[EToreo]

I appreciate your willingness but I doubt there is a way to do this. The lua team seems adamant that tread locking be a custom modification and build. The locking and unlocking functions are not even public, they expect you to modify the lua internal lua_state struct and interact with your modification. So, I really don't think there is a way to wrap customization like that.

If I think of something while I am cleaning up my experiment for prime-time, I will let you know.