Re: [email] Re: [GD-General] Scripting Systems

[Dan T. <da...@ar...>]

All engine calls are atomic, so after each call we try to guarantee the
validity of an object.

Of course, there could be situations where this is not possible, so perhaps
the premtive isn't good. However, I couldn't think of any other way to
prevent scripts from being able to eat all the processor.

The only break we get is since its user level threading, we control exeactly
when the preemption occurs.

Do people often just make one script stack, and have multiple files running
in it? Or one stack per script?

-Dan

----- Original Message ----- 
From: "Alen Ladavac" <ale...@cr...>
To: <gam...@li...>
Sent: Wednesday, January 21, 2004 4:21 AM
Subject: [email] Re: [GD-General] Scripting Systems


>
> ----- Original Message -----
> From: "Dan Thompson" <da...@ar...>
> > This method is vs. just running a script and creating the stack when the
> > message comes in. This seemed far too expensive, as you could be
creating
> > script stacks all over the place, and it also runs into the problem
where
> > the game locks because the scripts are being run in the same thread.
>
> AFAIK, one usual method is to make sure that all "yields" are always on
the
> bottom of the stack so you don't need to keep and store stack for each
> script. This of course rules out real preemptiveness. But... how do you
> handle that anyway? Don't you ever get problems with one script being
> interrupted in the middle of modifying some object and another one
accessing
> that same object in a half-valid state? And having scripts running on a
> different thread? Do you use some synchronizations when accessing other
> subsystems from scripts?
>
> Alen
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>