karl@sugar.uu.net (Karl Lehenbauer) (12/31/88)
I've been working with a midi input handler and a task that it signals that runs at priority 25. I know the manual says to use something lower but 'stat' shows other programs do the same plus Dan Baker's SMUS player uses 21, so it's a common practice for this severely realtime activity. Anyway, it seemed that after exiting (and to confuse things further, the example serial handler in the Exec reference manual never exits), 'z' would get a task held yet everything else seemed to work OK. Well, it turns out that if you don't SetTaskPri back to the original priority when you exit and you were launched from the CLI, the CLI will have the high priority and everything executed from that CLI will have the high priority. 'z', for no reason known to me, will get a task held if run at these high priorities. Z is kind of flakey, anyway, so it shouldn't come as too great a surprise. Anyway, setting the priority back when done has eliminated the z traps in two different programs of mine, so I thought I'd pass this along for anyone else who's having similar difficulties. -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018