[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Scripting language
On 12/19/06, Jakub Piotr CÅapa <jpc@xxxxxxxxxxxxx> wrote:
Bob Ippolito wrote:
> On 12/19/06, Jakub Piotr CÅapa <jpc@xxxxxxxxxxxxx> wrote:
>> Farai Aschwanden wrote:
>> > Hmm true for file opening. Adding paths needs the OS module, but you're
>> > right.
>> >
>> > I like the way Brian just sent before. I dont know any language that
>> > restricts its usage (would be neat feature for certain projects).
>>
>> Check PLT-Scheme for example. Neko also seems securable. An of course
>> LPC (search for DGD). The endless loop thing can be solved by
>> multithreading and killing any threads that run to long.
>
> That's not really a solution, pthreads can't be reliably killed. You'd
> still need a different abstraction that guarantees that you can kill
> threads in a reasonable amount of time.
There are languages with user-level threads (which are perfect for most
game logic kind of programming) like Erlang/PLT-Scheme AFAIK.
Still, could you please elaborate on the problems with killing pthreads
(let's forget about garbage collection and such)? Do you mean problems
with interrupting system calls?
By "different abstraction" I was referring to the kind of user-level
threads that you were referring to.
Erlang doesn't call them threads; they're processes. I don't know what
PLT-Scheme calls them, but if it's just "threads" then that's probably
a mistake -- most people associate threads with pthreads. The term
process is pretty overloaded too, but Erlang's processes are pretty
close to an OS process... they're just much cheaper to use (in time
and space).
Pthreads can't be reliably killed cross-platform, period. pthread_kill
is simply broken, it's not a very well designed API.
> You may want to take a look at embedding SpiderMonkey. It's designed
> to meet all of the given constraints (for the browser environment),
> and it's a language that's well known and easily learned (JavaScript).
That's probably a good idea however looking on Mozilla I'm unsure
whether it's protection from endless loops is flexible enough. (on the
other side it appeared only recently in the UI so maybe it's better
underneath) ;-)
It certainly works well enough to run it on a client.
-bob