🚀 go-pugleaf

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

>mlelstv@serpens.rhein.de (Michael van Elst) writes:
>>But why should every single program manage priorities when there is
>>a more easy solution ?

>Firstly, not every single program needs to do it -- only a program
>that wants to do some heavy computation and still interact with the
>user.

No. Every program that needs "heavy computation" for a noticable time.

>The best way to do that is create a thread, and if you're
>creating a thread anyway you may as well use a value other than "0"
>for the priority when you call CreateNewProc() (or others), right?

As I said, there are two ways. You could also create a thread for your
important interactive work (or use an existing one like input.device or
CON).

>Secondly, this allows a much simpler programming model for MUI that
>doesn't require locking and semaphore protecting of all data
>structures just to use the OO mechanism. 

MUI does use the same OO mechanism. It does need semaphore protection
if you spawn a new task that uses the GUI. And MUI (currently) doesn't
let you spawn tasks to handle the gadgets which would need semaphore
protection too.

>What you propose is for some MUI attributes to be modifiable by
>input.device, and/or some MUI methods to be callable by input.device.

That's what every standard gadget does.

>Currently they are not -- only *one* thread may do MUI stuff, which
>greatly reduces the complexity of programming MUI classes.

This is indeed the case. But it has its drawbacks and you need to
take care about this in other programs. So what is easier ? Take
care of the problem in the GUI toolkit or take care of it in every
program ?

>Programmers of MUI are supposed to use an OO paradigm. That means
>creating custom classes for everything, rather than simply writing an
>iterative program that uses a GUI toolkit.

No.

>It also means that writing
>custom classes should be easy, so the OO mechanism itself should not
>require you to deal with the possibility of multiple contexts
>executing your class.

No.

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

>The "internals" in this case are the details of the OO mechanism,
>BOOPSI. All you need to know is how to register a new class and its
>dispatcher, and how to receive methods -- just the basic BOOPSI stuff
>(although it's simplified a bit by some MUI glue routines). You don't
>have to worry about locking of structures or anything like that,
>because you're guaranteed never to have more than one context ever
>sending methods to your class.

That's easier and less capable. If you want to defer GUI operations
to a low-priority task then your class has to create a new thread
and again you have to communicate and synchronize.

>Enabling different contexts to send
>methods (such as input.device telling you to draw yourself in a
>depressed state) would require you to be aware of these issues.

It is more work. Sure. But it lets you concentrate the work in the
toolkit.

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

>This is correct, and is entirely consistent to that which you just
>said "No" to.

*sigh*

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

>Yes, MUI and gadgetclass both use BOOPSI. However MUI is *not*
>subclassed from gadgetclass.

>It's funny, but I'm sure I saw you complaining about this last year,
>so I assumed you knew it. Hmm... Perhaps it was someone else.

Perhaps you don't listen ? gadgetclass methods are called from
the application and from input.device. So it is not always the
same context. A method called from the application is not executed
at priority 20 and if the application tells the gadget to refresh
this happens at the priority of the application.

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

>No, you cannot. You are not allowed to send methods and set attributes
>to/of MUI objects unless they are on the same context.

I was talking about BOOPSI, not about MUI.

>>In fact, even simple
>>gadgetclass objects are created and configured on the application
>>context, event handling and refresh are done on input.device context.

>Yep -- gadgetclass objects do that alright. You're right on the money
>there. MUI objects, however, are not gadgetclass objects.

I'm not sure what you want to say with this. Obviously MUI objects
are not gadgetclass objects. This is one of the problems

>Yes. And look at what happens when the programmer isn't being *very*
>careful -- AmigaGuide.datatype and Grapevine's scrolling text display. 

No need to be careful.

>If you leave it up to the programmer and they make a mistake (which is
>easy enough), you can wind up with jerky mouse pointers using that
>system.

Same as with MUI that runs on pri 0 for everything.

>At least with MUI the worst that can happen is a sluggish
>application. The rest of the system is fine.

Same with careless design of gadgetclass gadgets. The rest of the
system is fine. I mean, the only thing we want to achieve with
priorities IS user responsiveness.

>Well, there is another way -- each MUI program could run its event loop
>at pri 1. :-) However that's not necessary. As I said, the worst that
>happens is the app becomes unresponsive, and that can be fixed simply
>by the user or the programs responsible or something like Executive
>running CPU intensive tasks at a lower priority.

So you have to "fix" all the programs or run "Executive" which does the
"fixes" automatically to use MUI.

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

>Sure -- and get frozen mouse pointers when you screw up,

So when you screw up with MUI there are no problems ?

>have locking
>problems associated with two different threads of execution running
>through your custom classes,

I don't think that you have problems. It is fairly easy.

>or having special cases for a few simple
>gadgets that can be cheaply refreshed by Intuition, etc.

It is not "a few simple gadgets". It is "close to all gadgets" because
every gadget has to generate feedback.

>At least with MUI, when you *do* spawn a task, it's entirely under your
>control. It has nothing to do with MUI, it will never be touched by
>MUI, it is a simple, normal, subtask. As I said, the subtasking has
>nothing to do with your OO system, which keeps the OO system simple.

The OO system is the same as that for gadgetclass.

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

>Yep. Even a professional programmer at C= can make a mistake.

Guess how old the datatype is, and no, that's not a mistake, it is
just not optimal.

And I bet that all the people _using_ the AmigaGuide datatype
wouldn't care.

>Imagine
>if the programmers of all those MUI programs on Aminet were exposed to
>the same difficulties...

Oh, but they _are_ exposed to the same difficulties. Have a look at all
the MUI applications that do not spawn subtasks for everything CPU
intensive. And then count the number of people that actually implement
MUI subclasses.

>"Sensible" in this case is obviously very much a matter of taste. I'd
>rather something that was simple, uniform, and completely general with
>no special cases and "gotcha"'s.

There are enough gotchas in either system. But AFAIK there are more
people using a GUI toolkit than writing one, and that's why I prefer
the gotchas in the toolkit.

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

>*NOT* just the GUI. Making 'ls' eight times slower by running just two
>tasks isn't helped by a pri 20 GUI.

But running it at pri 20 ensures that it is responsive.

>Nope, the GUI will depress buttons fine. But the delay in characters
>appearing that you have typed will more than compensate.

Why ?

>That delay
>won't exist if the CPU intensive stuff is at a lower priority.

Or if the whole text entry runs at the high priority (have a look
at string gadgets).

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

>It needn't.

It does.

>If I run 20 CPU intensive processes at pri 0, the machine
>is practically unuseable.

Sure. <5% of the CPU isn't much to be proud of.

>Running interactive stuff at a higher priority doesn't cause the CPU
>intensive stuff to miss out on any cycles they would've got anyway.
>But running CPU intensive stuff at the same priority has a huge impact
>on the interactive stuff, which keeps giving up portions of their
>quanta and waiting their turn again.

That's why you want to run interactive stuff at a higher priority.

>You're saying that characters be processed and displayed as they are
>entered, on input.device's context?

Yes.

>Cut and paste?

The highlighting (done by console.device) already happens on
input.device context.

>Reformatting as you
>type?

Is too slow anyway and is defered to a subtask.

>Online spell checking?

Produces no visual feedback and is CPU intensive anyway.

>The text editor probably won't be
>sluggish, but I bet your pointer sure becomes jerky and you'd want to
>avoid using your serial port for anything important.

No, why ? The high priority is just used to provide feedback.

>>>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.
>Yes. You are perfectly correct. Does that mean all apps should
>"suffer" because it "hurts" MUI more?

I'm just saying that MUI needs a smart scheduler as much as you running
lots of CPU intensive tasks in the background. On the other hand you
do not even use Executive to schedule everything. What happens to MUI
when you have a task that does lots of small I/O through the filesystem
(at pri 5 and 10) ?

Using a static priority scheme for the GUI (and other system tasks) is
much easier. This doesn't mean that a smart scheduler couldn't be used
for other programs where the scheduling algorithm is more appropriate.

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

>Of course it does. I suggest you try it sometime. Remember, AmigaOS
>isn't like Unix.

I remember that you use Executive which tries to make AmigaOS to
behave like UNIX.

>(As an aside -- using more threads, thanks to Exec's scheduler, will
>actually make your program relatively *faster* in a heavily loaded
>environment. Run 10 CPU intensive tasks, compare two programs A & B
>which do the same thing. A uses one thread, B uses 10. B will get
>about 1/2 the CPU in total, A will get about 10%. Guess which will go
>faster...)

Makes much sense, no ?

>Don't be rediculous. It's only a problem if the CPU intensive operation
>goes for long enough for the user to switch to another, interactive,
>task, and say "Oh, boy, this is unresponsive".

No. These programs could run in the background from a script and when
the interactive application he uses becomes sluggish he knows why.

>Umm... Let me think. I would say the easiest way would be to do it
>like AmigaGuide.datatype does it? Am I wrong? Has the
>AmigaGuide.datatype actually done it the hard way?

So, besides the flawed AmigaGuide.datatype, do you have another example ?

>From the programmers point of view, an OO system that doesn't
>*require* the programmer to worry about multiple contexts calling his
>custom class, and provides a consistent and complete mechanism for all
>classes, sounds like the simplest way to go.

If the programmer writes new classes.

>then it doesn't make any difference to use a
>"-1" for its priority instead of "0".

And it doesn't make a difference to use no thread because the GUI
toolkit already knows how to deal with user input quickly.

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

>The page was presented while loading. AWeb simply didn't respond to
>input. A special entry in Executive fixed this.

Sure. A special entry that effectively disabled Executive for AWeb
stopped Executive from interfering with AWebs output.

>IBrowse also presents
>a page while loading and responds to input, with or without Executive.
>It didn't need a special entry.

It does. You need to start Executive in the first place.

This just shows that Executive isn't the perfect solution. It works
fine with some types of programs and causes problems with other types
of programs.

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

>But it won't be starved of CPU by the event loop, now, will it?

Huh ? How can it be starved by the event loop ? The event loop doesn't
need much CPU time.

>Remember, I was suggesting run *all* CPU intensive subtasks at the
>same, lower priority.

... which is impractical.

>The event loop doesn't take much, and you want
>that to get the CPU immediately whenever you click something, anyway.

I get the CPU immediately when I process the event where it is
generated (i.e. in the input.device task). This is no longer
Intuition V33. Thanks to BOOPSI and gadgetclass I can now process
events and create feedback even for reasonable complex gadgets.

>once. If you were running Executive you would probably want to use one
>of the better schedulers or make a special entry in this case.

Or simply do not use Executive and run all the animations at some
equal reasonable priority.

>Not if they spawn lower priority subtasks for the CPU intensive stuff.
>AWeb already spawns subtasks, they're just at the wrong priority.

I fail to see that :) They are just at a priority that isn't handled
well by the Executive scheduler (but nicely by the Exec scheduler).

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

>Did you read my post? AWeb displayed a page while loading fine. It just
>didn't respond to user input.

I was refering to the claim that it did not display the page while
loading.

>displayed -- but the clicks on the gadgets went unheeded until the page
>was finished 2 1/2 minutes later

Sure, when Executive stalls the event loop then this is what happens.

>You
>claim MUI is the reason for wanting this and you don't need it
>otherwise.

No. I claim that you need it for MUI. MUI is _a_ reason. I never said
that you don't want it otherwise.

>of the CPU pie. They can't save it until later. Exec's scheduler is
>deadly for I/O bound tasks under a heavy load.

Not really. If a task is I/O bound then it just waits and doesn't
need much CPU time. Some CPU is spent in the I/O handler processes
and drivers (that's why they run at a high priority). Obviously
the RAM disk or PIPEs are a worst case.

>displayed, all perfectly -- with the one small problem that no user
>input was processed while Executive was fiddling with priorities. Weird.

Weird ? No. "Doctor, Doctor, when I run Executive then AWeb doesn't
handle user input while processing images." - "Well, then don't do that."

No ?

>consistent with 157s for a 600k page. Are you getting much less than
>12s for 50k pages (this is across ethernet, BTW)?

Maybe 3 or 4 seconds (with no graphics, graphics depend on datatypes
speed), part of this is rendering.

>>You can only stop network activity.

>That's a shame. I'd prefer it to progressively display pages as it got
>them from the cache, like it does when transferring them across the
>network.

Well, to me it looks as if it does this. But you cannot abort it which
would be a nice feature to add.

>Then I could click on them or go somewhere else without
>having to wait for it to finish. Currently it just locks up until the
>page is ready to be displayed.

It doesn't lock up here.

>>IBrowse becomes sluggish without Executive too.

>Yes, if you're running other CPU intensive tasks at the same priority.

That's what I'm saying.

>>And running interactive tasks at a high priority does the same and
>>was done by Intuition - to some degree - all the time. 

>It does *not* make the apps more responsive. *All* it does is make a
>few gadgets visually respond quickly.

It makes all gadets visually respond quickly. And that's what you want.

>The apps themselves will take
>longer to process your input --

Which is obvious, the machine is overloaded.

-- 
                                Michael van Elst

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