Godmar Back (gback@cs.utah.edu)
Thu, 18 Mar 1999 11:02:26 -0700 (MST)
Regarding the stopping of threads. We do not believe that a general solution that allows thread X to stop thread Y is necessary. It might be desirable, but it might also be impossible because of the problems involved in writing async-signal-safe code, but it's probably not necessary. Instead, we argue to introduce a process model: a given activity, such as a servlet, applet, or mobile agent, is encapsulated in a "process". Processes can be asynchronously killed by destroying (a la Thread.destroy) their threads. Processes are isolated from each other by giving them separate namespace, separate heaps, and separate CPU and network allocation. Shared state is kept in a "kernel", separated from user processes by a "red line" --- very much akin to the traditional user/kernel mode boundary. The kernel defers asynchronous cancellation requests while a thread executes in the kernel, protecting the integrity of essential data structures. The user/kernel abstraction also helps with resource control: kernel code is trusted and written with resource control in mind. For instance, kernel code has to be written to not throw arbitrary exceptions (like OutOfMemoryExceptions), instead, it is written to back out of such error conditions into "userland". Once in userland, an exception can be safely thrown. Note that this is very much like a normal OS such as BSD or Linux: processes executing in userland can be killed at any time, processes executing kernel code can only be killed at well-defined cancellation points. While not solving the general problem of thread cancellation, we find that a user/kernel boundary, a process abstraction greatly helps with solving the problems of containing units of untrusted code. It does not make stopping a means of programming (as Nilsen's atomic construct attempts to do). Of course, isolation between processes comes at a price. This price may be reflected in a higher overall memory consumption, and sometimes in the form of copying costs. For instance, a normal JVM like Sun's would intern all utf8consts: in a process-oriented JVM, you'd have to keep the symbolic information for each process separate in order to be able to separately account for them. - Godmar ---------------------------------------------------------------------------- To unsubscribe (or other requests) mailto:majordomo@media.mit.edu List archives, FAQ, member list, etc. http://gee.cs.oswego.edu/dl/javares/
This archive was generated by hypermail 2.0b3 on Thu Mar 18 1999 - 14:00:16 EST