|
From ‘lua.h’, debug hooks are void functions:
typedef void (*lua_Hook) (lua_State *L, lua_Debug *ar);
Regards, Dominique.
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Milind Gupta
Sent: lundi 31 mars 2014 16:34
To: Lua mailing list
Subject: Re: Pre-emptive round robin scheduler around Lua VM
Hi,
One thing I have seen in the Programming in Lua book is that the Hook function in C should always have a yield in the return statement so the debug_hook function should not be void and the last statement should be return lua_yield. Does that get rid of the interactions?
Regards,
Milind
On Mon, Mar 31, 2014 at 7:03 AM, Dominique Torette <Dominique.Torette@spacebel.be> wrote:
Hi,
I’m trying to build a kind of pre-emptive scheduler around Lua VM 5.2.
The idea is to execute different lua_State in “parallel’.
To give the illusion of parallelism, the idea is to run a thread for a given number of Lua VM instructions and then run the next thread in a list for this number of instructions and so on…
From the LUA regular API, when starting the execution of a thread, it is not possible to control the number of Lua VM instructions to execute.
But from the LUA debug API, it is possible to define a ‘hook’ to execute every COUNT of instructions.
The first idea was to install such hook and perform the round-robin scheduling from the hook. The lua_State of active thread seems to be saved before running such hook.
But I didn’t found any means to overwrite the thread to be resumed from the hook.
Then the idea was to ‘yield’ from the hook, back to the round robin scheduler.
This seems to work in the simplest cases. But I’ve noticed some strange “intereferences” when thread use coroutines on its own.
The Lua resume API has a ‘from’ parameter: int lua_resume (lua_State *L, lua_State *from, int nargs);
But from the description, I didn’t catch the how this param has to be used.
I’ve written a small “C” main program to illustrate the concept and the “interferences”…
In the program here below, the first iteration of the loop works as expected.
Then the L[0] and its coroutine are resumed, but the hook is reached faster than for the first iteration and the L[1] is rescheduled.
After L[0] will be never rescheduled, only L[1].
Thanks in advance, Dominique Torette.
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"
#include "lstate.h"
#include <stdio.h>
#include <setjmp.h>
lua_State* L[2];
lua_State* S[2];
int current;
int previous;
void debug_hook (lua_State *X, lua_Debug *ar)
{
printf("In debug_hook\n");
if((X->l_G)->mainthread != X)
{
printf("from coroutine \n");
}
S[current] = X;
current = (current+1)%2;
lua_yield ((X->l_G)->mainthread,0);
}
int main(int argc, char * argv)
{
int status;
L[0] = luaL_newstate();
luaL_openlibs(L[0]);
luaL_loadstring(L[0], "co = coroutine.create(function () while true do print('hi') coroutine.yield() end end) while true do print('hello') coroutine.resume(co) end");
lua_sethook (L[0],debug_hook,LUA_MASKCOUNT,500);
L[1] = luaL_newstate();
luaL_openlibs(L[1]);
luaL_loadstring(L[1], "while true do print('world') end");
lua_sethook (L[1],debug_hook,LUA_MASKCOUNT,500);
current = 0;
S[0] = L[0];
S[1] = L[1];
for(;;)
{
printf("Resume 1\n");
status = lua_resume (S[0],L[0],0);
printf("status 1 %d\n",status);
printf("Resume 2\n");
status = lua_resume (S[1],L[1],0);
printf("status 2 %d\n",status);
printf("Reloop\n");
}
}
Dominique Torette
System Architect
Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
www.spacebel.be
------------------------------------------------------------------------------
E-MAIL DISCLAIMER
The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.
SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.
SPACEBEL denies all liability where E-mail is used for private use.
SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------------------------------------------------------------------------
------------------------------------------------------------------------------
E-MAIL DISCLAIMER
The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.
SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.
SPACEBEL denies all liability where E-mail is used for private use.
SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------------------------------------------------------------------------