> I think you're thinking of native methods in terms of C code linked in
> by Java code via Runtime.loadLibrary()? As you say, allowing that
> sort of thing in JOS is real bad. The problem with this code is that
> is neither "contained" (its C not Java) nor is it trusted (A JOS
> kernel writer didn't necessairly write it.)
On the other hand, I can almost gaurentee that someone will want
to do it. Luckily, we don't have any shareholders, and can safely ignore
them :)
Did a little more thinking about Pat's information. It sounds
like the Right Thing for decaf to do is go with the massive rewrite, so
that all VM functions have a return code and take an exception reference
(pointer) as an argument, and thusly /have to/ write the
exception-handling code in at every level. -- Which because this is an o/s
project and not app project, is a Good Thing anyway. Because we need this
'delayed throw' ability in native libraries, it's rather pointless to
spend all the time it would take to implement a native throw scheme for
the rest of decaf, given that the 'delayed throw' will work.
And here I was thinking that we were close to finishing the
interperter because there's only one opcode left!
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
