Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rocky!ali
From: ali@rocky.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.amiga
Subject: Re: Bug(?) in SetTaskPri and recent Clock programs
Message-ID: <925@rocky.STANFORD.EDU>
Date: 4 Jan 88 04:51:05 GMT
References: <249@draken.nada.kth.se> <969@pur-phy>
Reply-To: ali@rocky.stanford.edu (Ali Ozer)
Organization: Stanford University Computer Science Department
Lines: 32
Keywords: SetTaskPri, ledclock.c, clock.c

In article <969@pur-phy> Nicholas J. Giordano writes:
>Several months ago, I accidently discovered something strange about
>a clock program I had been using.   ...
>The problem seems to be with incorrect calls to SetTaskPri.  The second
>argument is the new priority, and should be a SHORT.  However, the
>clock program mentioned above, along with the ledclock program posted
>recently, uses a LONG argument.  

A short while ago Tom Rokicki pointed out to me that if you execute a
program without "run," and the program changes its priority, the CLI, upon
exit, will have the new priority. Thus the program should probably 
keep the original priority around, and SetTaskPri() it upon exit:

 if (me = FindTask(NULL)) oldtaskpri = SetTaskPri (me,newpri);  /* At start */
    ...
 if (me) SetTaskPri (me,oldtaskpri); /* At end */

Of course, as you point out, normally clock programs are "run," so they 
have their own CLIs that go away when the programs exit.  

So, is it really a problem with SetTaskPri() getting the wrong argument, or
is it a problem with CLI getting stuck with a high priority and having some
later program not deal with it well? Don't forget that even if the manuals
state some system function argument is SHORT, it is still 32 bits and needs
to be LONG in Manx. It'd be real strange if SetTaskPri() really required a
16-bit argument. 

I just ran ledclock (not with "run" but with "ledclock"), exited, and indeed
CLI is at priority 5. Then I started up Emacs, exited, etc, and things 
seem fine.

Ali Ozer, ali@rocky.stanford.edu