Re: [platform-swt-dev] usage finalize() as last resortofresourcemanageme

["Ivan Markov" <ivan.markov@xxxxxxxxxx>]

I don't think the goal of SWT is to expose the "internals" of the OS.

OS.java & friends are neither documented, nor even stable. I even recall in
one of the tutorials for making custom native control, that they advised
against using OS.java even if some needed operating system functions are
exposed in this class.

As for the minimal overhead, I don't think VM-safety will sacrifice
performance.



----- Original Message ----- 
From: "Christopher Deckers" <chrriis@xxxxxxxxx>
To: "Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
Sent: Wednesday, November 08, 2006 11:02 AM
Subject: Re: [platform-swt-dev] usage finalize() as last
resortofresourcemanagement


> 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
> >
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev