ericmcg@pnet91.UUCP (Eric Mcgillicuddy) (10/08/90)
> Wrong. Most of the time the GS is spending CPU power doing the following busy wait: EventLoop: Mouse? Nope. Keyboard? Nope. goto eventloop [more..] Time slicing and process management would increase the effective throughput of the CPU by not busy-waiting. Any process calling GetNextEvent would be blocked until its input came thru. Note this is a step better than MultiFinder or LeapFrog, which just cycle the busy wait through multiple processes. Time Slicing and process management will make the GS work faster. >UUCP: bkj386!pnet91!ericmcg >INET: ericmcg@pnet91.cts.com -- Jawaid Bazyar | Blondes in big black cars look better wearing < Suppose every Heartbeat (1/60th of a second), after hearbeat tasks are handled, the active process is swapped? Obviously only the forground task requires user input, so input need only be Queued up awaiting the forground task to begin operating after some later heartbeat. The GS queues all ADB inputs, but has trouble with double clicks, s othis is fairly easy to do. The question is: What if GetNextEvent returns MouseDown, but then a task switch occurs? is the mouse poisition unchanged when the process it running again? I understand that the Toolbox is not re-entrant, so locking out a switch during ToolCalls seems like a reasonable precaution. Would this cause more problems than it solves? UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
jb10320@uxa.cso.uiuc.edu (Desdinova) (10/09/90)
In article <9010080345.aa20655@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes: > >Suppose every Heartbeat (1/60th of a second), after hearbeat tasks are >handled, the active process is swapped? Obviously only the forground task >requires user input, so input need only be Queued up awaiting the forground >task to begin operating after some later heartbeat. The GS queues all ADB >inputs, but has trouble with double clicks, s othis is fairly easy to do. > >The question is: What if GetNextEvent returns MouseDown, but then a task >switch occurs? is the mouse poisition unchanged when the process it running >again? > >I understand that the Toolbox is not re-entrant, so locking out a switch >during ToolCalls seems like a reasonable precaution. Would this cause more >problems than it solves? > >UUCP: bkj386!pnet91!ericmcg >INET: ericmcg@pnet91.cts.com You're right, the toolbox isn't re-entrant (it SHOULD be, we have to push parameters on the stack...) There is already the BUSY flag which does basically what you suggest, "locking" out processes from the tools if one is inside already. A better solution would include putting waiting processes on a queue automatically, instead of making the calling process check for a "busy" error, then put itself on the queue. That's the way it's currently supposed to be done. BTW, the 'queue' is a static array of length 4. Not terribly useful for extensions such as we are debating. A process queue manager would definitely be in order. I believe MouseDown records the current X & Y mouse positions at the time of the event. The wonderful Apple II programmers who designed the GS toolbox (after seeing the faults of the Mac toolbox) did almost everything right. My gripes are not important, since they really only apply to multiprogramming and GS/OS & ToolBox weren't designed for that. Oh, I misread what you said about locking out switches. Since the toolbox is part of the "kernel", it is more than reasonable to disable switching inside it. -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! | (B O'Cult) Apple II Users Unite! Storm the New Product Announcement and Demand Justice!
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/09/90)
Um.. get a copy of toolbox reference 3. The desk manager now has a Run Queue which works very much like the heart beat queue "and should be used in its place" according to the manual. BTW, the toolbox already has the beginnings of MultiFinder-like application switch support in it (Switch events and such). The problem we are attacking most fervently is that of pre-emptive multitasking and it can be done -- however it is a very good idea to not task-switch when any of the system busy flags are on. The other problem is that GS/OS itself was not designed for multiple applications (how do you context-switch the 32 or so system prefixes?); however I do not see any insurmountable barriers if Apple were to modify GS/OS toward a similar end. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/09/90)
In article <9010080345.aa20655@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes: >... Any process calling GetNextEvent would be blocked until its input came >thru. I thought it already did block until an event in its event mask occurred? >The question is: What if GetNextEvent returns MouseDown, but then a task >switch occurs? is the mouse poisition unchanged when the process it running >again? This is one reason for not using preemptive scheduling. Mouse events should consist of combined button status + cursor location, precisely to avoid the sort of situation you describe (which could occur even in a single-threaded environment, if various aspects of the mouse are handled independently). Not that it helps any with the IIGS, but to see one very nice solution to the entire "problem", you should look up Rob Pike's papers on Plan 9 and NewSqueak, published in various UNIX symposium proceedings.
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/09/90)
Todd (and anyone else interested in multitasking for the IIgs). Andy
McFadden has already developed context-switching code for the IIgs that
works, and I have modified it to properly avoid switching in the middle
of Toolbox or O/S calls. It requires GS/OS 4.0 or later, but that's not
too bad. Unfortunately, it is currently implemented only as a library
that allows an application to set up context-switching within itself. I
would love to see this expanded to allow true pre-emptive multitasking,
but there are problems, such as OS settings and ToolBox conflicts (read:
programs will try to draw into someone else's GrafPort). I think there
will need to be a lot of little workarounds to get it to work, but it
might be worth it. I am still working on interprocess communication and
a couple of other things, but I will try to release a preliminary
version soon. I would really like to see someone turn this into a true
multitasking system for the IIgs.
Incidentally, you can't use Run Queue or HeartBeat for context
switching, because you don't have access to the context of the program
being interrupted. LWP does it by patching directly into the VBL
interrupt vector, because of the unusual nature of what it does.
-----------------
Jeffrey Hutzelman
America Online: JeffreyH11
Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu,
jh4o@cmuccvma
>> Apple // Forever!!! <<6600prao@ucsbuxa.ucsb.edu (Parik Rao) (10/10/90)
runq only works under the desktop, unlike the heartbeat which works just about everywhere. So if one does use it in his or her programs, just keep that in mind. -- 6600prao@ucsbuxa.ucsb.edu/ucsbuxa.bitnet america online: AFA PARIK genie:P.RAO
rhyde@ucrmath.ucr.edu (randy hyde) (10/10/90)
>>> (and anyone else interested in multitasking for the IIgs)..
Many years ago (2 or 3) I wrote "Multi-ANIX", a multiprogramming shell
for GS/OS. I ran into the problem that one task would open two or three
files, the user would switch to a second process, which would open a file
or two and then issue the "close all files" command. This closed *ALL*
files including those in the first process. After discussion with Apple
DTS, I came to the conclusion that (1) I would have to rewrite a front tend
to GS/OS to trap all OPEN/CLOSE calls and handle this myself (a lot of
work), or I would have to wait for Apple to fix the problem. Has Apple
fixed this problem in GS/OS? Has Andy written this front end? Or has he
even considered this problem? I consider solution to this problem
tantamount to seeing a switcher or multifinder for the GS.
*** Randy Hyde O-)
.