On 12/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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)
Great! I'm looking forward to pressing Ctrl+Break, Ctrl+\ and especially Ctrl+C! Thank you! Elena 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 > > > > >
-- Thanks, Elena
