> 1/. As you may have noticed, I didn't get chance to update stdlib with some
> ASSERT macros last weekend. I *might* get chance this evening (but don't
> hold your breath).
Don't sweat it -- I've been too busy hammering out the
multi-processing stuff to do any coding myself.
> 2/. I meant the Java exception OutOfMemoryError and
> InvalidMonitorStateException .. as far as I could see, these and similar JVM
> exceptions aren't thrown and nor were they in the old code. But correct me
> if I'm wrong. As I said in my first mail, I'd be interested in trying to
> help sort this out if they are not yet functional.
No. Java-thrown exceptions ought to have worked in the old code
(not sure if I ever tested them), but the JVM never threw them on its own,
and a large part of this was the problem with getting the exception to be
thrown to the right place without using C++ exceptions. I'm very open to
suggestions/help.
> Another comment on code structure (which might have come out of the various
> discussions that have been going on, but I haven't had chance to read them
> yet): I think it would be useful to have a Process class in the C++. It
> would hold information about it class loader, threads/thread group, process
> id and, when we get some security infrastructure, the identity of the
> process owner etc.
Right now, a 'JVM' instance is defined by a classloader, and a
Scheduler (which maintains a list of runnable threads). A Process class,
or extensions to 'JVM' would probably come in handy, but I don't want to
start anything until we've figure processes out.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
