🚀 go-pugleaf

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