>And you are going to let the rest of us know how to do this ? Please.
>
>Christopher Cave
My solution (perhaps not unique, I don't claim it, but I haven't seen it used
elsewhere) exploits the fact that a job waiting for Input/Output with an
infinite timeout (D3=-1) will only ever get 'not complete' (D0=-1) returned if
MT.RELJB/SMS.USJB (release job from suspension) has been used on it.
MT.RELJB does not care whether the job is waiting I/O. Under these conditions
JB.STAT =-1 which is the same as job suspended (or =-2 waiting for another job
to complete). MT.RELJB will just zero JB.STAT (and zero address held in JB.HOLD
location if not 0). The result is the busy channel gets freed (CH.STAT=0)
immediately when MT.RELJB call exits, which is always via the scheduler.
My scheme is therefore: A main job opens a window and sets up a child job. It
passes to the child job a pointer to [the window channel ID and an action
routine pointer]. The main job then gets on with its task, whilst the child job
calls IOP.RPTR (read pointer) with an infinite timeout. When the main job has
something to update the window with it simply calls MT.RELJB with the childs job
ID and then continues with its task.
Meanwhile if the child job ever gets 'not complete' (d0=-1) from IOP.RPTR then
it performs the action routine supplied by the main job (*). Otherwise if it
gets 'complete' (d0=0) it performs the action associated with the pointer
result returned by IOP.RPTR. Since the waiting IOP.RPTR calls are done by the
scheduler the child job would not consume any time slices when idling.
(* In case the unsuspension was caused by an external malicious act (ie. not its
parent) it would need to verify some window operation was indeed required).
An alternative to this is the main job could perform the actual window operation
(once it has released the childs grip on CH.STAT), but it would then need to
signal the child job to resume IOP.RPTR (perhaps in response to ERR.NC the child
job suspends itself proper until the main job calls MT.RELJB again to restart
it).
The result is the main task gets on with the process (decoding image/playing
midi file etc) and the user gets a pointer on screen whilst seeing the progress
in the meantime (eg. able to press Cancel button, or Rewind etc). The only
effect of this approach is the pointer will flicker momentarily whenever the
window is updated, but most other WIMPs appear to do that (especially when the
pointer is over a redrawn area).
Regards,
Dave.
