harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Mon, 04 Dec 2006 10:04:56 GMT
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 <alexey.v.varlamov@gmail.com> wrote:
> 2006/11/21, Gregory Shimansky <gshimansky@gmail.com>:
> > Alexey Varlamov wrote:
> > > 2006/11/21, Evgueni Brevnov <evgueni.brevnov@gmail.com>:
> > >> On 11/21/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > >> > 2006/11/21, Tim Ellison <t.p.ellison@gmail.com>:
> > >> > > Evgueni Brevnov wrote:
> > >> > > > On 11/21/06, Geir Magnusson Jr. <geir@pobox.com> 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
> >
> >
>

Mime
View raw message