🚀 go-pugleaf

jasonb@cs.uwa.edu.au (Jason S Birch) writes:

>Unix or NT. It's hardly going to be much of an advantage if we're all
>too afraid to move anything below 0, now, is it?

But why should every single program manage priorities when there is
a more easy solution ?

>Yes. And for a long time now, we've been able to modify it.

This doesn't mean that every program has to do this.

>>So provide timely feedback as AmigaOS did it all the time: by using
>>input.device. It exists, it is the standard, it works well, you don't
>>need a scheduler that outguesses a programs intention.

>It also means that every class of MUI would be running at pri 20

This is rubbish. The only thing that runs at pri 20 is the event
handling. This is what already happens. But MUI classes defer everything
to the application. The right way is to defer only the slow operations
to the application (or another low priority task).

>you prefer: MUI apps running the bulk of their code at pri 20 because
>the programmer didn't know any better, or MUI apps running the bulk of
>their code at pri 0?

Programmers that _use_ a GUI toolkit do not care about this. Programmers
of new classes have to care.

>I believe ClassAct also does this, but makes
>it easy for the programmer to put parts of the custom class on the
>application's context if they feel it would take too long.

ClassAct doesn't make it easier. It isn't actually difficult.

>It is if you want to keep notification working on everything and you
>don't want the programmer to have to deal with the internals of your
>OO system (BOOPSI).

Programmers that use the toolkit do not have care about any internals
and programmers of new classes have to know the internals of the toolkit.
There is no difference.

>No -- because the OO system *itself* doesn't run at different
>priorities.

I am sorry. You have some wrong ideas about what "the OO system" is.
MUI uses BOOPSI too, the OO system does run at the priority you use it
at.

>Within a custom class, the OO mechanism is still running on
>the same context as the rest of the classes.

No. If you invoke a method from the user's program the priority isn't
suddenly changed and the method is not executed by input.device.

>Any method you call, any
>attribute you set, is all still on the same context.

Sorry, this is completely wrong.

>Internal functions
>to your class can be running on different contexts, but that has
>nothing to do with your OO mechanism.

As I said, MUI uses the same OO mechanism as gadgetclass.

>Within those other contexts, you
>can't call methods and set attributes of other objects directly.

This is wrong. Of course you can do this. In fact, even simple
gadgetclass objects are created and configured on the application
context, event handling and refresh are done on input.device context.

>It
>would get very messy to implement if you could, and you would need to
>implement it that way if you didn't want the whole thing running at
>pri 20 by default.

The methods do not run at pri 20 by default. And if you look at
datatypes (which are just special versions of gadgetclass) you see
that these can offload operations to a separate task or to the
application (by sending a sync message).

>>>So MUI does it all on the usual
>>>priority task's context, which makes MUI simpler but means the
>>>programmer has to be aware of the issues of GUI responsiveness and
>>>ensure his event handling loop is always ready and waiting.

>>Which is more difficult and interferes with more programs than simple
>>semaphore locking of data structures.

>Why is it more difficult?

Because you cannot ensure that the event handling loop is always
ready and waiting. Another task at default priority can slow down
your loop. There is no way to change that but to control priorities
of all tasks.

On the other hand it is simple to rely on input.device to run at pri
20 ahead of all other tasks.

>>Sure. I never said that existing BOOPSI gadgets are perfect but
>>datatypes already provide a method to offload expensive operations.
>>This is a function of the datatypes.library.

>That's right -- the *programmer* is left the task of offloading
>expensive operations,

No. If you use MUI _then_ the programmer is left the task of offloading
expensive operations. With datatypes this is done by the datatype
itself.

So writing of new classes is more difficult and writing of programs
that use the classes is easier.

>sluggish. A complex AmigaGuide document can stop my mouse pointer
>moving for a second or more.

As I said this is a flaw in the AmigaGuide datatype.

>Applications running CPU intensive tasks at pri 0 have always been
>annoying, because they make the system sluggish -- but at least we've
>always been able to move them if necessary.

CPU intensive tasks aren't just programs that consume all the CPU time.
For other programs, especially those with interactive input you'd have
to change the priority all the time.

>If they take long enough for you to want to do something else
>interactive in the meantime, think about using ChangeTaskPri, or Scout,
>or ARTM. Or use Executive, and let it happen automatically.

Or use a sensible scheme in your GUI toolkit so that this isn't a
problem.

>>You do not need to write special code to keep MUI and Executive happy.
>>That's what it is.

>Again. Sigh... This has nothing to do with MUI and Executive.

It has.

>Running
>CPU intensive processes at pri 0 *will* make the machine feel slower.

That's why you do not want to run the GUI at this priority.

>You *will* notice the effect in your text editor.

But you do not have to notice this in your GUI.

>You *will* notice
>that, while a button still depresses instantly, the application takes
>longer to respond.

That's obvious. If the machine is busy then it becomes slower.

>>Run a MUI program. Run another CPU-intensive program at the same
>>priority (i.e. 0: the default priority). Watch the MUI program to
>>become sluggish (if it isn't already).

>Watch your text editor also become sluggish.

This depends on your text editor. A text editor based on BOOPSI code
wouldn't become sluggish.

>Listviews will be slow to scroll. All of this is unnecessary, because
>it would all disappear if only the CPU intensive program was running
>at a lower priority.

This doesn't mean that you _have to_ lower the priority to keep the GUI
happy.

>It isn't responsive if (gasp) I run another CPU intensive task at
>priority 0,

It is more responsive than a MUI application under the same condition.

>or if it's coping with many connections and image
>decompressions while I'm trying to scroll through a large document.

Overloading a machine is never fast and changing priorities won't
change that.

>If the CPU intensive tasks it spawns ran at a lower priority, it would
>be. (This is without running Executive, BTW.)

Sure. But with Executive the various CPU intensive tasks do not
timeslice any longer (a 1 second timeslice is ridiculous).

>Many programs (eg. Real3D, IBrowse) spawn subtasks to do CPU intensive
>tasks. (Note that *only* CPU intensive programs need do this, other
>"standard programs" make no difference.)

I'm talking about close to any program. Even DIR or LIST have to
change priorities fore and back because they possibly sort the output.
Evey standard ANSI C program would have to be modified.

>This is *not* just about "keeping MUI happy", much as you would like it
>to be so. This is about making an 'ls' finish as fast as it could.
>About your text editor responding to your typing, or scrolling your
>document, when you want it to. Your CPU intensive task doesn't suffer
>from being at a low priority, but your interactive tasks sure as hell
>do if it isn't.

Yes. However, but what you do want is to run interactive stuff at
a higher priority than CPU intensive stuff. This can be done by
_lowering_ the priority of CPU intensive programs OR it can be done
by _raising_ the priority of the interactive programs.

Now what is easier, especially when you think that Intuition and the
console is based on the second model and the fact that most programs
that require interactive responsiveness use Intuition ?

>Of course not. I don't care if two Real3D drawtasks are exchanging the
>CPU every second or every 1/50th of a second.

But you do care wether AWeb presents you a page while loading or
wether Executive prevents this.

>It makes no difference
>to the actual completion time

But it makes a difference when the process is important and not
only the completition of the process.

>"CPU intensive" generally refers to things that take many seconds and
>use the CPU for their entire quantum. Tasks which are interactive will
>have a higher priority, will give up the CPU often, and will still
>appear to be running concurrently.

Yes, and CPU intensive tasks won't. Besides, you do not need time slices
if the programs do not use up their timeslices.

>Tasks which are currently receiving
>focus from the user will also be raised even higher, to ensure they
>are responsive.

But which is a wild guess. In case of AWeb or other programs that
are interactive _and_ need CPU time you lose.

>fast enough). It doesn't change Exec's scheduler, it doesn't make
>AmigaOS non-pre-emptive.

As a matter of fact it prevents (rapid) preemption of CPU intensive
tasks.

>>So another thing the user has to change to keep Executive happy.

>Executive couldn't care less. It's to keep the user happy.

The user would be happy without Executive (in this situation).

>Are you
>happy waiting 4 seconds for an 'ls' that *could* have been finished in
>0.5? Just because *two* other tasks are running?

Are you complaining about AWeb not displaying a page while loading ?

>>If page layout is fast enough there is no need for just another task.

>157 seconds for one page (the 600K page I was referring to earlier,
>showing our site's usage statistics which I check now and then) is
>quite a long time, so I suppose you're agreeing now that there *is* a
>need for just another task?

If it lasts 157 seconds then there is a need for another task (or at
least a heavy busy sign). But then I haven't seen anything like that
and I wonder how a 600k page (which is silly btw) can take so much
longer than the 50k pages that I have seen.

>If I click "<-", it still takes 18 seconds before the (small) previous
>page is shown again, and 119 seconds before the big page is displayed
>again if I then click "->", and I *can't* stop it if I change my mind.

You can only stop network activity.

>can prioritize them rather than making AWeb become sluggish under a
>heavy load (which IBrowse doesn't).

IBrowse becomes sluggish without Executive too.

>Hmm... Just about every point I've made about why wanting the CPU
>intensive code running on a separate thread at a lower priority than
>the main event-handling task is completely independent of both 
>Executive and MUI, yet all you ever do is blame Executive and MUI.

I do not blame it on Executive and MUI. I say that MUI requires
Executive or changes in almost every program. And I do not want to
change almost every program just to keep MUI happy. I'd rather use
something like MUI that does not require me to change these programs.

>computer to respond to my actions instantly when it can, and running a
>CPU intensive process at a low priority enables that.

And running interactive tasks at a high priority does the same and
was done by Intuition - to some degree - all the time. I'm not happy
if I had to change this and many other programs where you require
them to spawn off CPU intensive work to other tasks. And I'm not happy
to use Executive instead (at least not in its current incarnation)
because it has its own problems (stalling AWeb is only one).

Going the other way round is much easier and doesn't require changes.

Regards,
-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."