On 21 Feb 2001, at 21:07, dave westbury wrote:


> 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.
(snip)

FiFi has implemented a two job scheme like that for quite some 
time, except that the main job (not the one reading the pointer) 
passes an event to the job reading the pointer whenever it needs to 
update the window. Thjis ALSO causes a return from the read 
pointer loop. The job reading the pointer then suspends itself - the 
main job does whatever it has to do in the window and then 
releases the suspended pointer read job.


Wolfgang

Reply via email to