rokicki@rocky.UUCP (12/04/87)
Don't use the PopCLI I posted; if you stick in a disk when it is drawing its pretty patterns, the machine will lock up. Must be something to do with my Forbid(); Draw(); Permit(); so don't use that either until I figure out what's going on. (I just found this bug a few seconds ago and will debug it when time permits.) If it is the Forbid(); Draw(); Permit(); then I may have a hard time getting it to work! Re: Matt's detach comment, right on, Matt! Now, Jim Goodnow, will you let me post a new _main() for 3.4b from the one in Leo's robotroff and the new library sources for 3.4b? Or better yet, write one for me and post it? This detach business should be handled by the compiler, IMHO. Creeping featurism: I'm trying to add to this PopCLI something I've wanted for a long time---the ability to bring my editor to the front and activate it by hitting, for instance, shift-left-amiga-e, and to bring vt100 to the front with shift-left-amiga-v, and to cycle through the CLI windows with shift-left-amiga-c, and to bring TeX to the front with shift-left-amiga-t, and to get help on the current process by hitting help (by running `more' or something over a file in help:current-process-name) . . . I can't believe it broke. I'm sorry, folks, for wasting your time . . . -tom
ewhac@well.UUCP (12/07/87)
In article <799@rocky.STANFORD.EDU> rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: >Don't use the PopCLI I posted; if you stick in a disk when it is drawing its >pretty patterns, the machine will lock up. Must be something to do with my >Forbid(); Draw(); Permit(); so don't use that either until I figure out >what's going on. (I just found this bug a few seconds ago and will debug it >when time permits.) [ ... ] Consider the internal implementation of Draw(): OwnBlitter (); for (i=0; i < NUMBER_OF_PLANES; i++) { WaitBlit (); /* <--- This is the important bit */ FillBiltterRegisters (); StartBlitter (); } DisownBlitter (); Now, imagine a Forbid()/Permit() pair around this. When you call WaitBlit(), you may block. If you block, you temporarily give up your right to Forbid() the system. It is at this point that your drawing subtask (which I strongly suspect is similar to the one you posted recently) may get RemTask()ed out from under its feet. Great. The task now owns the blitter. The task also no longer exists. Can you say "system locked up tighter than a drum"? I knew you could. I said it before; I'll say it again: It is *NEVER* kosher (from an academic standpoint, admittedly) to arbitrarily RemTask() a running task. *ALL TASKS MUST RUN TO COMPLETION TO PRESERVE COSMIC SERENITY.* >Re: Matt's detach comment, right on, Matt! Now, Jim Goodnow, will you let >me post a new _main() for 3.4b from the one in Leo's robotroff and the new >library sources for 3.4b? Or better yet, write one for me and post it? >This detach business should be handled by the compiler, IMHO. > I'll consider this another request for a 3.4 version of Robotroff's _main. It's really quite easy, and I'll try to get around to this one as quickly as I can (is this a euphemism for "Real Soon Now"?). _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
rico@oscvax.UUCP (Rico Mariani) (12/09/87)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: >>Don't use the PopCLI I posted; if you stick in a disk when it is drawing its >>pretty patterns, the machine will lock up. Must be something to do with my >>Forbid(); Draw(); Permit(); so don't use that either until I figure out >>what's going on. (I just found this bug a few seconds ago and will debug it >>when time permits.) [ ... ] > > Consider the internal implementation of Draw(): > > OwnBlitter (); > for (i=0; i < NUMBER_OF_PLANES; i++) { > WaitBlit (); /* <--- This is the important bit */ > FillBiltterRegisters (); > StartBlitter (); > } > DisownBlitter (); > > Now, imagine a Forbid()/Permit() pair around this. When you call >WaitBlit(), you may block. If you block, you temporarily give up your right >to Forbid() the system. It is at this point that your drawing subtask >(which I strongly suspect is similar to the one you posted recently) may get >RemTask()ed out from under its feet. > > Great. The task now owns the blitter. The task also no longer >exists. Can you say "system locked up tighter than a drum"? I knew you >could. > > I said it before; I'll say it again: It is *NEVER* kosher (from an >academic standpoint, admittedly) to arbitrarily RemTask() a running task. >*ALL TASKS MUST RUN TO COMPLETION TO PRESERVE COSMIC SERENITY.* Why would anyone ever want to RemTask() a running task? Am I missing something here? If you want your program to stop then you send it a message/signal requesting it to do so and arrange for it to be waiting for such a message/signal (hopefully blocked on it when idle). If you don't know enough about the program to know what signal etc. it's waiting on then you're just asking for trouble RemTask()ing it. When designing this kind of stuff you have to remember that Amiga system calls are not atomic, in fact most IO related (graphics/keyboard/dos/etc) calls can block your task for a while so count on this. It doesn't matter whether you're Draw()ing, Move()ing, BltBitMapRastPort()ing or whatever, RemTask() is just plain the wrong thing to do to stop a program. Then again... I could be mistaken :-) -Rico Can't wait to see the new PopCLI... PopCLI gets my vote for the all time handiest and dandiest utility around. Way to go guys! -- ...{watmath|allegra|decvax|ihnp4|linus}!utzoo!oscvax!rico or oscvax!rico@gpu.toronto.EDU if you're lucky [NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode] [CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche] [Cat food: Nine Lives, Cat Chow, Meow Mix, Crave]