🚀 go-pugleaf

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

>Thanks to Exec's scheduler, you can *if running at a high enough
>priority*. Priority 0 is plenty high enough if CPU intensive stuff is
>lower.

That's the key. CPU intensive stuff is _not_ lower. You don't want
to manually change the priorities and you do not want every program
to change its own priorities.

>*And*, most importantly, their priority.

The default priority of a process is zero.

>>It is much simpler to provide timely feedback if the user interface
>>runs at a higher priority. 

>Bingo.

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.

>Another one is wanting to have a uniform notification scheme which can
>work uniformly on any attribute of any object. Running your GUI event
>handling code on two separate tasks, one at pri 20 and one at the usual
>pri, would make this very messy.

This isn't more difficult than other code that needs several tasks.
And if you use MUI you have to do the same. Wether your code spawns
that process or you use the existing input.device process.

>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.

>It also
>means it's more uniform -- as has been noted before, not even GadTools
>does *all* it's GUI response at pri 20 -- some gadgets are refreshed by
>input.device, some aren't.

No. It is maybe not perfect, but it does what you want: offload
expensive operations to the user process while providing immediate
feedback at high priority.

>You even have some things -- like the
>AmigaGuide datatype laying out AmigaGuide documents -- running at pri
>20 when they really shouldn't be.

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.

Generic BOOPSI doesn't have this (mainly because these are simple
gadgets with quick methods) but you can do this on your own.

>Or, to put it another way -- you can lower the priority of tasks not
>directly communicating with the user.

Again. That is something YOU have to do.

>Executive simply tries to do this automatically. That's all.

And Executive has its own problems....

>>Usuability of the user interfaces and
>>other real-time tasks now becomes the policy of individual programs
>>and their programmers.

>Only if they don't separate event handling from CPU intensive code

Think about programs that do not do event handling. Something simple
as a compiler or anything written in straight ANSI C.

>>With the standard Exec scheduler you can even allow it to run on
>>the same priority. 

>But what do you gain from doing so?

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

>Of course they don't. I'm not talking about changing AWeb so it won't
>"interfere" with MUI --

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).

>I'm talking about making AWeb *itself* more
>responsive,

AWeb is responsive. If you run Executive at the same time it isn't.

>In case it isn't obvious -- in order for a MUI program to remain
>responsive, all that's required is that no CPU intensive tasks be
>competing with it for the CPU at the same priority.

So none of the standard programs is allowed to run, because these
programs surely do not change task priorities to keep MUI happy.

>Of course it doesn't. Over a long period of time they get the same
>amount of CPU (all else being equal), but in one second they can get
>vastly different amounts.

Which means that it is pretty unusuable.

>get one seconds' worth of CPU, but they would've got it in bursts of
>about 0.05 seconds at a time.

And that's what we want to create the illusion of concurrency:
multitasking.

>I would make an entry for them in Executive's preferences.

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

>As I said, nothing I've said has anything to do with "making MUI
>happy".

Sure. To make MUI happy you have to run CPU intensive processes
at priorities below 0.

>Given he's already spawned off network transferring and image decoding
>onto subtasks, is it really such a terrible thing to want page layout
>there as well?

If page layout is fast enough there is no need for just another task.
I can also imagine that page layout is partially locked with the input
because you change the window gadgets.

Anyway, this is not a problem unless Executive tries to outguess the
programs.

>>Yes. And no, I do not run Executive anymore.

>Well, even before I ran Executive, I always set priorities manually to
>ensure processes like my editor ran higher than processes like Real3D.

If you work in a shell, do you set the priorities for every command
you start ?


-- 
                                Michael van Elst

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