Re: [email] Re: Scripting Systems

"Alen Ladavac" <[email protected]>
Newsgroups gmane.games.devel.general
Message-ID <[email protected]>
Well, running it on one stack worked ok for us during last several years,
and lot of other people use that. However, I cannot claim which technique is
most often. I believe that most people do cooperative instead of preemptive
for scripts, and general multithreading is avoided like a plague, unless
really necessary (loading in the background, etc.).

Just my 0.02$.

Alen


----- Original Message -----
From: "Dan Thompson" <[email protected]>
To: <[email protected]>
Sent: Wednesday, January 21, 2004 20:01
Subject: Re: [email] Re: [GD-General] Scripting Systems


> 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" <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, January 21, 2004 4:21 AM
> Subject: [email] Re: [GD-General] Scripting Systems
>
>
> >
> > ----- Original Message -----
> > From: "Dan Thompson" <[email protected]>
> > > 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
>
>
>
> -------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>



-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.