Resource exhaustion

Hi,

what to do to prevent Dolphin program exhausting windows resources? Simptoms
are: program starts substituting fonts, and quite soon it becommes unable to
display icons.

Program does not do any graphic, it is based on number of multicolumn
listboxes. It does not use database and odbc. It does use custom draw
extension posted here on this newsgroup.

Are there good sugestions what to do, are there well know resource eaters
(apart from sql statements), and what objects to try to relealse by hand?

Thanks,

Davorin Rusevljan

In a good spirit of responding to my self..

since most of complaints come in the form:

Can't hold Icon fromId: 'icons\mysell.ico'

would calling:

IconImageManager current purgeImages

from time to time ease my problems?

Davorin Rusevljan

Davorin Rusevljan wrote in message <8u9cd7$c0uc$[hidden email]>...
>Hi,
>
>what to do to prevent Dolphin program exhausting windows resources?
Simptoms
>are: program starts substituting fonts, and quite soon it becommes unable
to
>display icons.

Davorin Rusevljan wrote in message <8u9esm$c5ug$[hidden email]>...
>would calling:
>IconImageManager current purgeImages
>from time to time ease my problems?


oops. no, it seems it deletes all Icons for good. I thougt it would load
them laizily.

Davorin Rusevljan

Davorin,

> what to do to prevent Dolphin program exhausting windows resources?
Simptoms
> are: program starts substituting fonts, and quite soon it becommes unable
to
> display icons.
>
> Program does not do any graphic, it is based on number of multicolumn
> listboxes. It does not use database and odbc. It does use custom draw
> extension posted here on this newsgroup.

I haven't looked at it; does it rely on finalization for cleanup?  If so,
and you have lots of elements getting drawn, then it's possible that
finalization isn't happening soon enough.  Independently, ELVs don't care
for errors during drawing, so make sure your draw/item/text/etc blocks are
correct.

In general, have a look at

    http://www.object-arts.com/wiki/html/Dolphin/WindowsGraphics.htm

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:8u9q7s$17p1t$[hidden email]...
> Davorin,
>
> > what to do to prevent Dolphin program exhausting windows resources?
> Simptoms
> > are: program starts substituting fonts, and quite soon it becommes
unable
I don't know how one should "properly" hook into Dolphin's window-message
event dispatch chain; there are a variety of low level Win32 techniques
available.

But given you know how to hook in, then if the issue is finalization latency
then you might want to take advantage of the Win32 message that gets issued
when resource memory is low.

WM_COMPACTING

  "Sent when the OS detects that more than 12.5% of its time
   in the last 30-60 seconds has been spent scavenging
   for additional memory resources."

Then, have the handler for that window message invoke the garbage collector
to generate a GC finalization cycle.

It might also pay to hook into the code that loads/creates the resources and
put error/restart handlers in place that also invoke a GC finalization
cycle.

These are some of the simpler ways I resolved the resource constraint issues
for QKS Smalltalk VM for Win32. Other techniques get into the actual design
of Resource related classes, caching, and lifecycle issues that are probably
not applicable.

In general finalization based design for resource management, as Dolphin has
done it, is a great way to go because it enables a Smalltalk abstraction
layer to lazily manage caching much more efficiently than Win32. But the
technique is greatly benefitted from identifying appropriate gc trigger
points.

--
-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

Bill Schwab wrote in message <8u9q7s$17p1t$[hidden email]>...

Bill, thanks for the advice. I came up with potential suspect - localization
code. Before any view is shown, it gets translated, and it's font gets
changed to the character set defined for the locale. The trouble is that it
seems to me that this font gets created each time when view is shown. Here
is the snipet:

setCharSetForView: aView
 | font |
 "take the font of the control, change the charSet, set font"
 aView font notNil ifTrue: [
  font := aView font.
  "23 - offset for charSet inside LOGFONT"
  font logFont bytesAtOffset: 23 put: (ByteArray with: self charSet).
  font detachHandle.
  font realize.   "as far as I can see this creates a new font..."
  aView font: font.
 ].

Davorin Rusevljan

Davorin

You wrote in message news:8ub3di$e7mk$[hidden email]...

>.... Before any view is shown, it gets translated, and it's font gets
> changed to the character set defined for the locale. The trouble is that
it
You will be leaking fonts here, which I have found in the past very quickly
exhausts GDI resources. #detachHandle will orphan the old Font (or
"...relinquish ownership to the caller" as it says in the method comment),
and cause it to be lost. You must #free the Font, e.g. see
Font>>isUnderlined:.You probably don't need to explicitly realize it either
since this should happen lazily, however this will not do any harm if the
Font is properly destroyed.

Rather than directly accessing into the bytes of the LOGFONT, why not send
it a #lfCharSet: message? It is "uncompiled" in the 3.0 development
environment, and the field is therefore accessed via DNU, but in an
application deployed using the normal options it will have a compiled
accessor. Perhaps the best thing to do would be to add appropriate loose
methods to Font, e.g.:

Font>>charSet
 ^logfont lfCharSet

Font>>charSet: anInteger
 anInteger = self charSet ifFalse: [
  logfont lfCharSet: anInteger.
  self free]

If the Font is selected into other views, then modifying it in place is not
a good idea, and you would be better off modifying a copy, so putting it all
together:

setCharSetForView: aView
    | font |
    font := aView font.
    font notNil ifTrue: [
        font := font copy.
        font charSet: self charSet.
        "Or without the loose methods
            font logFont charSet: self charSet.
            font free."
       aView font: font].

Regards

Blair

Blair McGlashan wrote in message ...
>You will be leaking fonts here, which I have found in the past very quickly
>exhausts GDI resources. #detachHandle will orphan the old Font (or
>"...relinquish ownership to the caller" as it says in the method comment),
>and cause it to be lost. You must #free the Font, e.g. see


Thanks Blair, I will give it a try this afternoon/evening. Do you think that
in addition to not leaking them, some font caching would be advisable, or is
it unnecessary? I ask because this piece of code is executed each an every
time any view gets shown. Since app is running for at least 6 hours, and
people tend to use it extensively, this could turn out to quite large number
of requests for logFonts to windows.

Davorin Rusevljan

Davorin

You wrote in message news:8ubbjb$edt5$[hidden email]...
> ...
> Thanks Blair, I will give it a try this afternoon/evening. Do you think
that
> in addition to not leaking them, some font caching would be advisable, or
is
> it unnecessary? I ask because this piece of code is executed each an every
> time any view gets shown. Since app is running for at least 6 hours, and
> people tend to use it extensively, this could turn out to quite large
number
> of requests for logFonts to windows.

We have found that Windows own font manager is quite effective on 32-bit
Windows (for once I am including 9x in that) and that it is not necessary to
cache fonts as it used to be in the old Win 3.x days. I would assume it is
not necessary unless it turns out to be a problem in practice.

Regards

Blair

http://www.object-arts.com

I am still testing but it seems the problem with resources has gone away.


Davorin Rusevljan