harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Mon, 04 Dec 2006 10:23:42 GMT
On 12/4/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> 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 <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
> > >
> > >
> >
>



-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message