On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> And more generally, to have one VM per language type, rather than per
> app.
I suppose one problem you'd have to deal with is the tendency for a
segfault to take out the entire VM.
The C [only] programmers reading this are, of course, all used to
writing programs that can crash. Certainly we don't want this to happen,
but when we do something wrong, we get a nice segfault and fire up GDB
on the aborted program to start debugging it. The rest of your desktop
keeps running. Yeay.
Because a {pyGTK, java-gnome, gtk#, whatever} application is of course
linking against the native GTK library, when you get a crash in GTK the
*program* you are crashing is the {Python VM, Java VM, ...}
If you were to try and get all the programs running in a managed
language into a single process, then we'd have to figure out how to not
take out all the other applications that happen to be running in that VM
when your buggy thunders in.
[Java, for example, *is* capable of running _many_ disparate
programs - infrastructure like separate ClassLoaders and fairly
rigorous visibility and security policy between classes provides
for this, and you see it in production use all the time in
Servlet containers, enterprise application servers etc - and it
all works quite well **provided** they are all written in pure
Java and make no native calls]
People across the computing spectrum have been tantalized by this
prospect for a long time, but I get the impression that everyone gets
hung up on the "what do you do when a native library call crashes your
VM" issue.
Otherwise, wouldn't it be wonderful to have a single Python VM, a single
Java VM, etc. Shit, make it a kernel module.
Oh well.
AfC
Bangalore
Attachment:
signature.asc
Description: This is a digitally signed message part