[iyonix-support] Re: Lazy Task Swapping on Iyonix/RISC OS 5.11

In article <d80ce13b4e.rogerarm@xxxxxxxxxxxxxxxxxxx>,
   Roger Darlington <rogerarm@xxxxxxxxxx> wrote:

> OK, I have tried increasing the default slot of OPro from 1680k to
> 3000k. I can report that I got no pixel lines after over 20 mins of
> intensive use of Variations plus OPro. This seems to have fixed the
> pixel lines.

This one may be worth asking on David Pilling's list (unless David is
lurking on this list), because I'm not sure how Ovation is designed.

My thinking behind trying a larger wimpslot in the first place was that the
wimpslot may define how much space Ovation claims initially, but if it runs
out of space I've noticed that OvationPro is capable of extending it's own
wimpslot (watch the task display when you're creating a document in
Ovation). I suspected that perhaps when it reaches the maximum value of its
default slot, it then tries increasing it automatically - which possibly
results in LTS with other applications.

I don't really know enough about internal memory management in RISC OS to
know exactly what happens when a task starts increasing it's own wimpslot -
but it seems that this is what /may/ be causing the problem.

> But does this mean that apps do not obey their own wimpslot (bearing in
> mind all the reported faults with a lower wimpslot)????

Applications can (and do) increase their own wimpslot - just watch the task
display when Ovation (or Variations, for it does the same thing) are loaded.

Indeed, I wonder what happens if two applications simultaneously decide to
increase their wimpslots? Is there perhaps a clash, or mis-allocation of
slot space or something?[*]

> Does it mean there's a bug in RO 5 about making apps obey their own
> wimpslot?

I'm not sure about bug, but I'm not entirely sure what the -max value of a
wimpslot does - because obviously if applications can increase their own
wimpslot beyond the -max value then it seems to defeat the object of having
a max - unless that's a max 'initial' value, which again seems a bit
pointless.

> However: I DID GET A CRASH: Several thumbnails in Variation were
> corrupted with coloured pixels, and several thumbnails went completely
> blank. The error message issued by Variation was: AODT at FC183290 code
> 2935. I've no idea what that means.

My suspicion is that is might be something to do with [*] above.

> Moreover, Variations NEVER behaves like this when used without OPro
> (with or without the increased wimpslot in OPro). So, there's still
> something going on.

Might be worth finding another application which can also increase its own
wimpslot if it needs to - and seeing if that also crashes when used in
conjunction with Ovation or Variations.

> Does the plot thicken?

Quite probably - but I do feel we might be getting a /bit/ closer to a
cause....

Paul

P.S. Ovation ignores its own wimpslot anyway, as on my copy it says;
WimpSlot -min 1648K -max 1648K
and I've just double-clicked on it to load, and immediately it comes up
with 2392K in the task manager. If you start typing in a new document you
can see the wimpslot value flickering in the task display, so it's
obviously doing something to chunks of memory.

-- 
Paul Vigay                 __\\|//__            Life,
                           (` o-o ')        the Universe
http://www.vigay.com -----ooO-(_)-Ooo------ & Everything ------

101 uses for a Bill Gates: 5: A crash test dummy
---
To alter your preferences or leave the group, 
visit http://www.freelists.org/list/iyonix-support
Other info via http://www.freelists.org/webpage/iyonix-support

Other related posts: