Re: Help needed with lua_resume / lua_yieldk with lua threads

[Ram Prasad <emailrampi@...>]

Hi All,

Just thought I'd update you'll on my issue:

The issue was this :

When I was calling a lua script function (data()) for a client
session, say session1, I was setting its _ENV upvalue to the table
corresponding to session1.
When lua script function called my "sleep(n)" API, I did the lua_yieldk...

Now, when session2 came in, I called the same lua function (data()),
and I changed the function's _ENV upvalue to that corresponding to
session2.
So, when the lua function called sleep(n) and yeilded, the lua
function's (data()) _ENV upvalue was still set to that of session2.

And when the timer fired for session1, and we resumed the lua script
function (data()), the lua function still had its _ENV still set to
that of session2 - leading to problems.

In my test code, I am able to fix it as follows :
In the continuation function, I reset the _ENV upvalue of the lua
script function (data()) to that corresponding to that of the current
session  (i.e. one for which timer fired).
This ensures that when lua script function executes after the sleep,
it finds the right _ENV.

Not sure whether doing the above in the continutation is the right
thing. I think I should be doing it in lua_userstateresume by
redifining those. Will dig more on that.

Just thought I will update y'll on this.

Cheers,
Rampi


On Mon, May 27, 2013 at 10:10 AM, Ram Prasad <emailrampi@gmail.com> wrote:
> Resending it again, ensuring plain text mode. Looks like my earlier
> post was got garbled for some reason:
>  http://vlists.pepperfish.net/cgi-bin/mailman/private/lua-l-lists.lua.org/2013-May/032013.html
>
> Sorry for the duplicate email.
>
> Cheers,
> Rampi
>
>
> ---------- Forwarded message ----------
> From: Ram Prasad <emailrampi@gmail.com>
> Date: Mon, May 27, 2013 at 5:58 AM
> Subject: Help needed with lua_resume / lua_yieldk with lua threads
> To: lua-l@lists.lua.org
>
>
> Hi All,
>
> I needed some help with lua_resume / lua_yieldk usage with lua threads.
>
> This is with lua-5.2.1.
>
> I have simple tcp echo server application. It has a main lua state (L)
> and for each client session I associate a lua thread (T), i.e. created
> with lua_newthread(). And when the client session connects or sends
> data I pass it thru a function (say connect or data) in a lua script.
> This lua script has been loaded earlier during program init time.
>
> I want each client session have its own environment - so that it can
> set some globals or state and not affect other client sessions.
>
> So, far I am able to do this by setting the up value (1) of the
> function to be called with the client session specific environment
> before calling the lua function from the C code.
>
> Now, I wanted to try to use the yield and resume functionality and
> implement a non-blocking API that can be called from lua script.
> As a test, I tried add a "sleep(n)" function. Essentially, when the
> lua script calls "sleep(n)",
> -  the C code starts a timer for n seconds and returns with "lua_yieldk()".
> - When the timer expires, I call lua_resume again
> - in the continuation function, I just return 0 as I don't need to
> anything in this case (correct?)
> - and then the script continues
>
> This seems to work fine when there's only one session "sleeping" at time.
>
> Now, while the first session is sleeping, a second session comes in,
> and the C code sets up the env corresponding to the second session and
> calls lua_resume to invoke the lua script function. And the script
> calls "sleep(n)", so the second session also goes to sleep.
>
> But, now, when the first session wakes up, and the script continues,
> it's environment is now that of the second session. So, it gets the
> wrong information and that's a problem.
>
> How can I ensure that that when the first session wakes up, it finds
> its own environment and not that of any other session that might have
> come (and gone) in between. (I am hoping I've described my problem
> clearly).
>
> The other question I had is about the lua_resume API:
>
> int lua_resume (lua_State *L, lua_State *from, int nargs);
>
> In my case, I have the lua thread T (which is client session specific)
> and the global lua state L. For the "from" parameter, the manual says
> this : The parameter from represents the coroutine that is resuming L.
> If there is no such coroutine, this parameter can be NULL  . It was
> not clear to me whether I should be setting "from" to NULL or "L", my
> global lua state . I am thinking it should be NULL, in my case as, for
> the first call to lua_resume, there's no coroutine that's resuming it
> or when I call lua_resume after the timer expiry, it is the same.
> There's no co-routine which is actually resuming it.
>
> Cheers,
> Rampi
>
> --
> It's not that I'm so smart, it's just that I stay with problems longer
> - Albert Einstein.



--
It's not that I'm so smart, it's just that I stay with problems longer
- Albert Einstein.