[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] usage finalize() as last resort ofresourcemanagement
|
Should all the SWT ports be "type-safe"? I mean, it is one of SWT's
goals to expose the internals of the OS, and have the least overhead
as possible. If you want VM-safe calls, then maybe a separate SWT port
should be used (SWTSwing when production-ready for example)
-Christopher
On 11/8/06, Ivan Markov <ivan.markov@xxxxxxxxxx> wrote:
FYI: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110621
----- Original Message -----
From: "Ivan Markov" <ivan.markov@xxxxxxxxxx>
To: "Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
Sent: Wednesday, November 08, 2006 10:43 AM
Subject: Re: [platform-swt-dev] usage finalize() as last resort
ofresourcemanagement
>
> Your case can be overcome if the GC keeps references to the Font,
foreground
> color and background color that are set in it (and the rest of the
> resources, of course).
>
> I don't say such a scheme is simple to implement, but it is in no way
> "impossible".
> I tried to do something like this in SWT/Fox, but implemented on the
handle
> level.
>
> By the way, the current working of SWT also may easily cause segmentation
> fault. Consider:
> GC gc = ...
> Font font = ...;
> gc.setFont(font);
> font.dispose();
>
> gc.drawText("blah");
>
> This blows up on Fox and probably on GTK+ and Motif too.
> On Windows this will generate GDI error, and unpredictable display result,
> but not GPF.
>
> So tracking resource references will help avoid the upper problem too, and
> will move SWT one step towards "secure API", i.e. one that:
> - when NOT used carefully still does not result in JVM GPF (99% of the
Java
> API has such protections, including AWT is like this)
> - afterwards, it could be possible to declare SWT "safe" for use from
> unsigned applets in that there is no way for the applet code to cause GPF
or
> in some other way elevate its privileges by memory corruption.
>
> Of course, whether all that is worth the effort is another topic..
>
> -Ivan
>
>
> ----- Original Message -----
> From: "Peter Centgraf" <peter@xxxxxxxxxxxx>
> To: "Eclipse Platform SWT component developers list."
> <platform-swt-dev@xxxxxxxxxxx>
> Sent: Tuesday, November 07, 2006 11:37 PM
> Subject: Re: [platform-swt-dev] usage finalize() as last resort of
> resourcemanagement
>
>
> > Danail Nachev wrote:
> > > The discussion which I
> > > try to find is answer to the question: why finalize() isn't used as
last
> > > resort for freeing system resources as it is used for FileInputStream
> > > for example? Am I missing something here?
> >
> > The last comment on the bug refers to the specific issue in this case,
> which
> > is explained in the article. Some things that appear to be garbage on
the
> > Java side (because there are no Java references to them) will still be
in
> use
> > (because there are OS-level references to them). This bad sequence
could
> happen:
> >
> > 1. Java objects initialize some resources.
> > 2. OS sets up references to resources.
> > 3. Java objects go out of scope.
> > 4. Java objects are finalized.
> > 5. OS resources are disposed.
> >
> > 6. Java call delegates to OS.
> > 7. OS tries to use resources.
> > 8. Pain and suffering.
> >
> > Take the example (from the article) of an X-Windows GC and Font. A GC
can
> > refer to a Font via OS-level structures. From the Java side, the Font
> appears
> > to be garbage, but it's actually still in use. If the Font is disposed
by
> a
> > finalizer, things will blow up in an ugly way. Your JVM dies with a
> > Segmentation Fault or somesuch platform-specific nonsense.
> >
> > --
> > Peter Centgraf
> > _______________________________________________
> > platform-swt-dev mailing list
> > platform-swt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
