problem with lua_resume/lua_lock

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

problem with lua_resume/lua_lock

Zimmermann
Hi there,

I was playing around with lua_lock / lua_unlock (lua-5.0 work0, Windows)
using the following lua_user.h:

<<<
#include <windows.h>
#undef LoadString

#define LUA_USERSTATE CRITICAL_SECTION cs;
#define lua_lock(L) EnterCriticalSection(&((L)->cs))
#define lua_unlock(L) LeaveCriticalSection(&((L)->cs))
#define lua_userstateopen(L) InitializeCriticalSection(&((L)->cs))

Testing it with the following lua code the interpreter freezed:

<<<
function test()
    local i = 0
    while 1 do
        i = i + 1
        coroutine.yield(i)
    end
end

co = coroutine.create(test)
for i = 1, 10 do
    print(co())
end
>>>

I think I have found the problem in lua_resume (ldo.c):
The call

  status = luaD_runprotected(co, resume, &ud.err);

in lua_resume() ends up in luaD_precall(), which tries to lua_unlock() the
never locked coroutine 
state before the actual coroutine function is called.

I changed lua_resume() to

LUA_API int lua_resume (lua_State *L, lua_State *co) {
  CallInfo *ci;
  struct ResS ud;
  int status;
  lua_lock(L);
  ci = co->ci;
  if (ci == co->base_ci)  /* no activation record? ?? */
    luaG_runerror(L, "thread is dead - cannot be resumed");
  if (co->errorJmp != NULL)  /* ?? */
    luaG_runerror(L, "thread is active - cannot be resumed");
  if (L->errorJmp) {
    setobj(&ud.err, L->errorJmp->err);
  }
  else
    setnilvalue(&ud.err);
  lua_lock(co); 						/* MZ: added
this line */
  status = luaD_runprotected(co, resume, &ud.err);
  lua_unlock(co);					/* MZ: added this
line */
  if (status == 0)  
    move_results(L, co->top - ud.numres, co->top);
  else {
    setobj(L->top++, &ud.err);
  }
  lua_unlock(L);
  return status;
}

wich seems to solve the problem but I might have overlooked something.
My knowlage of the internal is not realy good.  Does everybody know if
this change breaks something?

Best regards
Maik Zimmermann


Reply | Threaded
Open this post in threaded view
|

RE: problem with lua_resume/lua_lock

Zimmermann
Sorry,

I meant anybody, not everybody in the question in my last mail.

Maik Z

Reply | Threaded
Open this post in threaded view
|

Re: problem with lua_resume/lua_lock

Dan Partelly
Please, Where did you got "lua-5.0" ? I tought is not available yet.

Dan

----- Original Message ----- 
From: "Zimmermann, Maik" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, August 07, 2002 4:57 PM
Subject: RE: problem with lua_resume/lua_lock


> Sorry,
> 
> I meant anybody, not everybody in the question in my last mail.
> 
> Maik Z
> 


Reply | Threaded
Open this post in threaded view
|

RE: problem with lua_resume/lua_lock

Zimmermann
In reply to this post by Zimmermann
Hi Dan,

you are right, the official current version is lua 4.0.1.

The version I spoke of was lua 5.0 work0, a kind of development snapshot for
the upcomming version 5.0.  It is available at
www.tecgraf.puc-rio.br/lua/work 

Look at message 8672 from Thu 6/6/2002 in this list.

regards
Maik

Reply | Threaded
Open this post in threaded view
|

Re: problem with lua_resume/lua_lock

Roberto Ierusalimschy
In reply to this post by Zimmermann
The whole idea of lua_lock/lua_unlock is to control accesses among different
threads sharing the same global state. That means that all trheads should
use the same mutex.

So, your macros should be like

  #define LUA_USERSTATE CRITICAL_SECTION *cs;

where all LUA_USERSTATE would point to the same CRITICAL_SECTION
variable. That shared variable would be already locked when you first
resume a new thread.

(We could have defined a kind of LUA_GLOBALUSERSTATE in global_State,
but there would be no way to access it with an abstract lua_State.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: problem with lua_resume/lua_lock

Zimmermann
In reply to this post by Zimmermann
> So, your macros should be like
>
> #define LUA_USERSTATE CRITICAL_SECTION *cs;

Many thanks for your answer.
I will change my code according to your suggestion.

regards
Maik

Reply | Threaded
Open this post in threaded view
|

lua_yield behaviour

Dan Partelly
Please , what is the exact behavoiur in the next scenario:

A Lua script calls an external C function. This function schedules for
execution a
stack of actions, and imediately calls lua_yield() to stop the script from
running further.
Where exactly will LUA VM stop in this scenario ? (Execution of script will
be resumed
when a ListenerObject will be signaled upon the stack of actions is empty.)

Thx , Dan



----- Original Message -----
From: "Zimmermann, Maik" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, August 07, 2002 5:57 PM
Subject: Re: problem with lua_resume/lua_lock


> > So, your macros should be like
> >
> > #define LUA_USERSTATE CRITICAL_SECTION *cs;
>
> Many thanks for your answer.
> I will change my code according to your suggestion.
>
> regards
> Maik
>


Reply | Threaded
Open this post in threaded view
|

Re: lua_yield behaviour

Roberto Ierusalimschy
> A Lua script calls an external C function. This function schedules for
> execution a stack of actions, and imediately calls lua_yield() to stop
> the script from running further. Where exactly will LUA VM stop in this
> scenario ?

Exactly after the call. When you resume the thread, it will start at the
next opcode after the OP_CALL that called the C function.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Evaluating LUA

Dan Partelly
Donno how interesant this is for you guys, but after evaluating 5 or 6
possible choiches for a scripting language, I choosed LUA as my project
scripting language, despite the fact I was way more familiar with other ones
(In fact my LUA experience was 0 till few days ago ...).  The descision was
made especially because  LUA's fallback and tag methods features.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Luiz Henrique de Figueiredo
>Donno how interesant this is for you guys, but after evaluating 5 or 6
>possible choiches for a scripting language, I choosed LUA as my project
>scripting language, despite the fact I was way more familiar with other ones
>(In fact my LUA experience was 0 till few days ago ...).  The descision was
>made especially because  LUA's fallback and tag methods features.

It's always interesting to know why people choose Lua (not LUA, BTW :-).
When you finish your project, please consider adding it to our list
	http://www.lua.org/uses.html
	http://www.lua.org/uses-form.html
Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Benjohn Barnes-2
In reply to this post by Dan Partelly
on 8/8/02 6:06 PM, Dan Partelly at [hidden email] wrote:

> Donno how interesant this is for you guys, but after evaluating 5 or 6
> possible choiches for a scripting language, I choosed LUA as my project
> scripting language, despite the fact I was way more familiar with other ones
> (In fact my LUA experience was 0 till few days ago ...).  The descision was
> made especially because  LUA's fallback and tag methods features.

If you had the time to put together a document, it would be very
interesting, and useful (for me at least), to read the reasoning behind your
choice. Preparing that would be an involved undertaking though, although the
document could be useful to yourself, should you find yourself loosing the
faith at any point, or needing to explain your decision to someone else :)

Cheers,
    Benj


Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Dan Partelly
Ill consider writing a doc on this, but certainly not now. Sorry, but is a
bit time consumming to write docs about design decisions. It involves
documenting propsed targets for this scripting subystem, integration with
main software body, comparative anlysis, and argumentation on the
conclusions.

If you plainly ask me what I did not like to Lua, is its "pascualish"
sintax. Im a beleiver in
if() { } and not in if - then - end. Brackets add more clarity and
efficinecy. But this is an extremly minor thing, considering it's other
advantages. Due to fallbacks and tag methods , I can adapt it to my needs
with extremly few modifications to the core of VM . Not to mention  that I
can use it as well to simply parse and implement complex NPC templates  and
Weapon templates using multiple inheritance, store special effects
templates, mood templates, apart from Npc,Camera, and level goals/flow
scripting . All AI code is C++, however, callbacks to scripts will be
employed for certain events. (Ya, the code is intended to go into a game).

>> be useful to yourself, should you find yourself loosing the  faith

It wont happen. Should I integrate it and hand  over to other ppl a sintax
and command draft to begin level scripting , there is no way back. But I am
very confident Lua won't dissapoint me at all. Ahh and another thing.  Lua
aint overbloated and "feature" packed like many other scripting languages
out there. Simple things are like diamonds.

Best regards, Dan




----- Original Message -----
From: "Benjohn Barnes" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Thursday, August 08, 2002 8:55 PM
Subject: Re: Evaluating LUA


> on 8/8/02 6:06 PM, Dan Partelly at [hidden email] wrote:
>
> > Donno how interesant this is for you guys, but after evaluating 5 or 6
> > possible choiches for a scripting language, I choosed LUA as my project
> > scripting language, despite the fact I was way more familiar with other
ones
> > (In fact my LUA experience was 0 till few days ago ...).  The descision
was
> > made especially because  LUA's fallback and tag methods features.
>
> If you had the time to put together a document, it would be very
> interesting, and useful (for me at least), to read the reasoning behind
your
> choice. Preparing that would be an involved undertaking though, although
the
> document could be useful to yourself, should you find yourself loosing the
> faith at any point, or needing to explain your decision to someone else :)
>
> Cheers,
>     Benj
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Philippe Lhoste
In reply to this post by Dan Partelly
> If you plainly ask me what I did not like to Lua, is its "pascualish"
> sintax. Im a beleiver in
> if() { } and not in if - then - end. Brackets add more clarity and
> efficinecy. But this is an extremly minor thing, considering it's other
> advantages.

Some share this idea, I don't care, even if I like C conciseness.
Now, I did a little Pascal and a lot of Basic :-)

> Due to fallbacks and tag methods , I can adapt it to my needs

Say, you aren't planning to use the 3.2 version, aren't you? Fallback term
isn't used since the 4.0 version, they are quite obsolete...

> with extremly few modifications to the core of VM . Not to mention  that I
> can use it as well to simply parse and implement complex NPC templates 
and
> Weapon templates using multiple inheritance, store special effects
> templates, mood templates, apart from Npc,Camera, and level goals/flow
> scripting . All AI code is C++, however, callbacks to scripts will be
> employed for certain events. (Ya, the code is intended to go into a game).

NPC, weapon, AI. We shouldn't have guessed :-)

> >> be useful to yourself, should you find yourself loosing the  faith
> 
> It wont happen. Should I integrate it and hand  over to other ppl a sintax
> and command draft to begin level scripting , there is no way back. But I
am
> very confident Lua won't dissapoint me at all. Ahh and another thing.  Lua
> aint overbloated and "feature" packed like many other scripting languages
> out there. Simple things are like diamonds.

I believe many people here share the same idea. Python, eg., is interesting,
but quite daunting when you have to download 8MB just to try a little
script... At least on Windows. There may be smaller packages, without all the
libraries, but they are hard to find. And I doubt it will beat the size of Lua...

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Dan Partelly
>> 3.2 ..... isn't used since the 4.0 version, they are quite obsolete...

Nope, Ill use one of future stable versions of 5.0 work as a base. yielding
and coroutines
suport can greatly simplify my life.

Regards, Dan


Reply | Threaded
Open this post in threaded view
|

RE: Evaluating LUA

Brownsword
In reply to this post by Dan Partelly
I actually like the fact that Lua is not C-like.  There are already too many
C-like languages and it becomes rather confusing to have to deal with all
the variations-on-a-theme.  Lua's choice of syntax avoids that problem.

My biggest concern in adopting Lua is the overhead of the garbage
collection.  In a real-time environment on machines which have poor random
memory access times, having the GC walk across the data structures is very
time consuming.  This will greatly constrain how we can use the language
unless an alternative mechanism can be retrofitted.  I'd much rather have
this addressed by the original authors, but I haven't seen any discussion of
it...?


-----Original Message-----
From: Dan Partelly [[hidden email]]
Sent: Thursday, August 08, 2002 3:26 PM
To: Multiple recipients of list
Subject: Re: Evaluating LUA

.
.
.
If you plainly ask me what I did not like to Lua, is its "pascualish"
sintax. Im a beleiver in
if() { } and not in if - then - end. Brackets add more clarity and
efficinecy. 
.
.
.

Reply | Threaded
Open this post in threaded view
|

RE: Evaluating LUA

Luiz Henrique de Figueiredo
In reply to this post by Dan Partelly
>I actually like the fact that Lua is not C-like.

To use a quote from http://www.lua.org/quotes.html
	"I use Lua because I like the language more than C++." 
	-- Paul Bleisch, in rec.games.programmer. 

:-)

>My biggest concern in adopting Lua is the overhead of the garbage collection.

We're planning to add generational GC to Lua. Perhaps even for 5.0 final.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Evaluating LUA

Cameron Kaiser-2
In reply to this post by Brownsword
> I actually like the fact that Lua is not C-like.  There are already too many
> C-like languages and it becomes rather confusing to have to deal with all
> the variations-on-a-theme.  Lua's choice of syntax avoids that problem.

<aol>Me too!</aol>

-- 
----------------------------- personal page: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Point Loma Nazarene University * [hidden email]
-- TRUE HEADLINE: Prostitutes Appeal to Pope ----------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: Evaluating LUA

Joshua Jensen
> > I actually like the fact that Lua is not C-like.  There are already 
> > too many C-like languages and it becomes rather confusing 
> to have to 
> > deal with all the variations-on-a-theme.  Lua's choice of syntax 
> > avoids that problem.
> 

Except it's the biggest hangup when trying to convert C and Javascript
users... "Why do tables use braces and functions do not?" ... and
they're the main people I always try and get to use Lua.

-Josh


Reply | Threaded
Open this post in threaded view
|

RE: Evaluating LUA

Eric Tetz-2
--- Joshua Jensen <[hidden email]> wrote:
> Except it's the biggest hangup when trying to convert C and Javascript
> users... "Why do tables use braces and functions do not?" ... and
> they're the main people I always try and get to use Lua.

Yeah, I prefer JavaScript's C-derived syntax, too, but if Lua used curly braces you would start
expecting C-like operators too (++, --, +=, *=, <<, >>, etc).  Lua stays leaner by omitting these,
and it's probably best to not having a syntax that constantly reminds of their absence.

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Reply | Threaded
Open this post in threaded view
|

RE: Evaluating LUA

Sean Middleditch
On Fri, 2002-08-09 at 18:41, Eric Tetz wrote:
> --- Joshua Jensen <[hidden email]> wrote:
> > Except it's the biggest hangup when trying to convert C and Javascript
> > users... "Why do tables use braces and functions do not?" ... and
> > they're the main people I always try and get to use Lua.
> 
> Yeah, I prefer JavaScript's C-derived syntax, too, but if Lua used curly braces you would start
> expecting C-like operators too (++, --, +=, *=, <<, >>, etc).  Lua stays leaner by omitting these,
> and it's probably best to not having a syntax that constantly reminds of their absence.

If someone with the skills coded a C-like parser/compiler for Lua
bytecode, these issues might be resolved.  I'm doing something similar
for my extension language - the bytecode interpreter is cleanly
separated from the compiler, allowing programmers to write and link in
their own parsers.  I plan on using this feature to, for example, add a
state-machine parsing language that lets me build AI using a mixture of
clean state machine keywords and script code.  The same could be done to
build a special cut-scene language and so on, so that you still only
need one language core, but can use semantics/structures appropriate for
the task at hand.

> 
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com



12