Hi, I've implemented safe-shutdown of java threads as it was at the beginning of this thread. No significant problems were encountered while implementing. Find the patch at http://issues.apache.org/jira/browse/HARMONY-2391. Here is the details:
1) Java thread stack unwinding in shutdown mode implemented. 2) Proper processing of SIGINT (Ctrl+C) implemented. 3) Proper processing of SIGQUIT (Ctrl+\) implemented. 4) JNI function FatalError reimplemented. 5) Smoke test infrastructure extented to compile native sources. 6) New smoke tests were added to test VM shutdown. Note: Enjoy pressing Ctrl+Break to see java stack traces :-) (Ctrl+\ on Linux) Thanks Evgueni On 11/22/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/11/21, Gregory Shimansky <[EMAIL PROTECTED]>: > Alexey Varlamov wrote: > > 2006/11/21, Evgueni Brevnov <[EMAIL PROTECTED]>: > >> On 11/21/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > >> > 2006/11/21, Tim Ellison <[EMAIL PROTECTED]>: > >> > > Evgueni Brevnov wrote: > >> > > > On 11/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > > >> > >> > > >> Evgueni Brevnov wrote: > >> > > >> > > >> > > >> > As it was discussed earlier (and I think agreed) the > >> System.exit() > >> > > >> > should terminate entire process the VM is running in right > >> after it > >> > > >> > executed shutdown hooks and finalizes. > >> > > >> > >> > > >> I don't think so. How could you embed the VM in another program? > >> > > > > >> > > > My initial understanding was that System.exit() shouldn't terminate > >> > > > the process. But the experiments proved the opposite. AFAIU if you > >> > > > want to embed the application then it should not call > >> System.exit(). > >> > > > >> > > I was surprised to see the results of you experiment too -- I'd have > >> > > failed that Java pop-quiz question! > >> > > > >> > > > I don't see any problems to extend the proposal to the case of > >> > > > System.exit() so that the process will not be stopped. But, do > >> we want > >> > > > such incompatibility with RI? > >> > > > >> > > No, we can't change that -- if people expect the program to exit() > >> it we > >> > > will see hangs everywhere. As somebody (I forget) wrote at the > >> time, it > >> > > becomes the responsibility of the app to set the security policy to > >> > > disallow exit() if they expect the Process to live on. > >> > > >> > Policy would not help here actually, javadoc for > >> > java.lang.RuntimePermission says: > >> > "The "exitVM.*" permission is automatically granted to all code loaded > >> > from the application class path, thus enabling applications to > >> > terminate themselves." > >> > And normally it is hardly possible to bypass the default system > >> > classloader, one need to hack standard classloading delegation > >> > mechanism. > >> > >> Is there any way to influence default policy? > > AFAIU this not a policy, just hardcoded static permissions granted by > > the system classloader when a class is defined - much like any > > URLClassLoader grants access to the class own URL. > > Do you mean that a java applet may bring down a browser process? I had > an impression that applets have a very strict set of permissions, like > no access to the disk, etc. Do they have exit still allowed? Nope until they are loaded with application loader. Normally applet should be loaded by dedicated classloader which does not grant them much permissions + strict (aka sandbox) policy should be active. > > -- > Gregory > >
