Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: How do I force a context switch?
Message-ID: <8708070015.AA10387@cogsci.berkeley.edu>
Date: Thu, 6-Aug-87 20:15:45 EDT
Article-I.D.: cogsci.8708070015.AA10387
Posted: Thu Aug  6 20:15:45 1987
Date-Received: Sat, 8-Aug-87 14:19:23 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Institute of Cognitive Studies, UC Berkeley
Lines: 28
Summary: argh! to history

In article <3677@well.UUCP> tenney@well.UUCP (Glenn S. Tenney) writes:
>Remembering wayyyy back (V21, 23 or 24 days, it all gets muddled)
>there WAS an exec call to force a context switch.  It was dropped
>'cause "they" felt there was no need for it.  I pointed out that
>if I was running my own multitasker (there are good reasons to do
>this) that I'd really like to just say "offer the cpu", but no.....

One place that I wanted to use this call was right before a Forbid().
If I Forbid() at the start of my quantum, rather than at any old place,
I am less likely to exceed my time, and I minimize the effect on the
system.

For this (and other) reasons I'd sure like to see that call come back.

I had another situation where there was a known dead time during some
data aquisition from the parallel port.  The reader task *had* to 
Disable() to meet timing requirments, but at certain points it could
guarantee X ms of free processor time.  It ended up not returning the
time to the system because there was no easy guarantee that some other
(lower priority) task might not Disable() and screw things up. [It would 
have had to SetFunction() Disable(); messy!. Setfunction()'ing Forbid()
would be worthless since that is often implemented as a macro]


|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."