yorkw@stable.ecn.purdue.edu (Willis F York) (01/20/91)
Well In WSHELL it checks for Hanging Forbids. and i have seen 2 programs that Have "these features" One is Newlook - A program that alters the close/ftont/back gadgs. the other is Preferences offa tha 1.3 disk! What IS a hanging Forbid? -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
alex@bilver.uucp (Alex Matulich) (01/24/91)
In article <yorkw.664344861@stable.ecn.purdue.edu> yorkw@stable.ecn.purdue.edu (Willis F York) writes: >Well In WSHELL it checks for Hanging Forbids. >and i have seen 2 programs that Have "these features" >One is Newlook - A program that alters the close/ftont/back gadgs. >the other is Preferences offa tha 1.3 disk! And yet another is Lace, which switches the workbench between 200/400 lines. >What IS a hanging Forbid? Forbid() is an Amiga C function call which disables multitasking so the calling program can have sole uninterupped access to the Amiga's services, system structures, etc. It is usually followed by Permit() to re-enable multitasking when the program finishes doing whatever it needs. If Permit() was not called before the program terminates, you have a "hanging forbid," which used to cause lockups in the OS versions 1.2 and earlier, and still causes problems with 1.3. I use WShell too, and haven't had a problem with these offending programs with it. >yorkw@ecn.purdue.edu Willis F York -- _ |__ Alex Matulich (alex@bilver.UUCP) /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"
chris@genly.UUCP (Chris Hind Genly) (01/25/91)
>In article <yorkw.664344861@stable.ecn.purdue.edu> yorkw@stable.ecn.purdue.edu (Willis F York) writes: >Well In WSHELL it checks for Hanging Forbids. > . . . >What IS a hanging Forbid? Forbid() is used to switch from preemptive to non-preemptive task scheduling. Permit() switches back to preemptive task scheduling. They should be used in pairs. Whenever you call Forbid(), within a short amount of time you should call Permit(). If you just call Forbid(), and don't call Permit(), then you have a hanging Forbid(). [Very impolite. You've just turned your machine into a Macintosh :-) ]. You would use Forbid()/Permit() when accessing structures shared by several tasks to prevent the structure from being modified while you were working on it. * * * \|/ * _______ --O-- ____/ KC1VP \____ * /|\ * ______/ (203) 389-8680 \______ ______/ Eggplant Software Tools \________ ______/ 95 Fountain Terr., New Haven, CT, USA, 06515 \_______ / Chris Hind Genly chris@genly.uucp uunet!hsi!genly!chris \ ----------------------------------------------------------------
djohnson@beowulf.ucsd.edu (Darin Johnson) (01/26/91)
In article <1991Jan23.201301.2046@bilver.uucp> alex@bilver.uucp (Alex Matulich) writes: >Forbid() is an Amiga C function call which disables multitasking so the >calling program can have sole uninterupped access to the Amiga's services, >system structures, etc. It is usually followed by Permit() to re-enable >multitasking when the program finishes doing whatever it needs. >If Permit() was not called before the program terminates, you have a >"hanging forbid," which used to cause lockups in the OS versions 1.2 and >earlier, and still causes problems with 1.3. I use WShell too, and haven't >had a problem with these offending programs with it. Hmmn, I recall reading somewhere that if you remtask a task that has outstanding forbids, that these will be removed. In other words, you can Forbid(), do some cleanup code, exit the program, and everything should be ok. There are other ways to do safe cleanups, but they often take extra paranoid-style code. (so, am I wrong, or did I really read this?) -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (01/29/91)
>>>>> In article <chris.8320@genly.UUCP>, chris@genly.UUCP (Chris Hind Genly) writes:
Chris> You would use Forbid()/Permit() when accessing structures
Chris> shared by several tasks to prevent the structure from being
Chris> modified while you were working on it.
No, you should use SEMAPHORES when accessing structures shared by
several tasks to prevent the structure from being modified while you
were working on it.
--
--------------------------------------------------------------------
himacdon@maytag.uwaterloo.ca watmath!maytag!himacdonridder@elvira.enet.dec.com (Hans Ridder) (01/30/91)
In article <1991Jan28.171326.6363@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >>>>>> In article <chris.8320@genly.UUCP>, chris@genly.UUCP (Chris Hind Genly) writes: >Chris> You would use Forbid()/Permit() when accessing structures >Chris> shared by several tasks to prevent the structure from being >Chris> modified while you were working on it. > >No, you should use SEMAPHORES when accessing structures shared by >several tasks to prevent the structure from being modified while you >were working on it. What semaphore would you suggest I use to access the Exec Task list? I assume you were trying to say that when there is a choice, Semaphores should be used instead of Forbid/Permit, because they are more "multitasking friendly". However, Semaphores are useless if you're the only one using them. In the case of *most* of the V1.3 system structures and lists, Forbid/Permit is *required*, i.e. there is no choice. >himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
jesup@cbmvax.commodore.com (Randell Jesup) (01/30/91)
In article <2405@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >What semaphore would you suggest I use to access the Exec Task list? A) You must Disable() to play with this list (and have a pretty damn good reason for doing so!) B) Exec (and it's lists) was written before there were SignalSemaphores in the system, so it's stuck with locking methods used in the initial implementation (usually Forbid()). Unfortunate but unavoidable. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
yorkw@stable.ecn.purdue.edu (Willis F York) (01/30/91)
>>What semaphore would you suggest I use to access the Exec Task list? > A) You must Disable() to play with this list (and have a pretty damn > good reason for doing so!) > B) Exec (and it's lists) was written before there were > SignalSemaphores in the system, so it's stuck with locking methods > used in the initial implementation (usually Forbid()). Unfortunate > but unavoidable. (I started this Thread).... What's a Semaphore? a Signal of some type eh.. I use "showlist.rexx" and it displayes all semephores, but there are never any.. Why use one? I guess one program would say... I need the "colors" of the WB to be unchanged so i'll "LOCK" them "UP" (Like preferences would do?) then "unlock" the when it's done? . -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
ridder@elvira.enet.dec.com (Hans Ridder) (01/31/91)
In article <18291@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <2405@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >>What semaphore would you suggest I use to access the Exec Task list? > > A) You must Disable() to play with this list (and have a pretty damn > good reason for doing so!) Arghhh! What a fool am I! I realized this after I posted, but haven't been able to get back to news for a day or so. You see, I was just checking to see if anyone was paying attention.... (Won't work, huh?) > B) Exec (and it's lists) was written before there were > SignalSemaphores in the system, so it's stuck with locking methods > used in the initial implementation (usually Forbid()). Unfortunate > but unavoidable. Exactly! I was just trying to clarify the previous poster's general statement that semaphores should be used instead of Forbid()/Permit(). I wanted to point out that there's times when you have no choice, but I committed a technical gaffe in the process. Glad someone here is awake. Thanks Randell, for keeping the record straight! I'll go away now. >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
chris@genly.UUCP (Chris Hind Genly) (02/02/91)
>In article <chris.8320@genly.UUCP>, chris@genly.UUCP (Chris Hind Genly) writes: > >Chris> You would use Forbid()/Permit() when accessing structures >Chris> shared by several tasks to prevent the structure from being >Chris> modified while you were working on it. >In article <1991Jan28.171326.6363@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: > >Hamish> No, you should use SEMAPHORES when accessing structures shared by >Hamish> several tasks to prevent the structure from being modified while >Hamish> you were working on it. No? You're very definite about that. How about saying something to support your position. Semaphores aren't provided for Dos structures. In this case you must use Forbid()/Permit(). Also if you're atomic task is quick, Forbid()/Permit() should be quite fair. Semaphores have their advantages. For one, they only involve those tasks interested in a particular shared datum, not every task in the system. If your access is going to take a while, and you are in control of all tasks doing the access, semaphores would be preferred. * * * \|/ * _______ --O-- ____/ KC1VP \____ * /|\ * ______/ (203) 389-8680 \______ ______/ Eggplant Software Tools \________ ______/ 95 Fountain Terr., New Haven, CT, USA, 06515 \_______ / Chris Hind Genly chris@genly.uucp uunet!hsi!genly!chris \ ----------------------------------------------------------------