Path: utzoo!utgpu!utfyzx!oscvax!jan
From: jan@oscvax.UUCP (Jan Sven Trabandt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Frienndly waiting (not hogging the CPU)
Message-ID: <623@oscvax.UUCP>
Date: Thu, 14-Apr-88 13:10:57 EDT
References: <8804120421.AA04436@jade.berkeley.edu>
Reply-To: jan@oscvax.UUCP (Jan Sven Trabandt)
Organization: Ontario Science Centre, Toronto
Lines: 29
Summary: 

In article <8804120421.AA04436@jade.berkeley.edu> SLMYQ@USU.BITNET writes:
>
>You might want to open up the timer.device directly, but the only advantage
>this would give is you could do something else while it's "ticking" - it's
>asynchronous.  You can use this method within tasks as well as processes,
>but if you just want a synchronous wait within a task, using WaitTOF()
>is probably better.
>                                Bryan

The timer.device can be used asynchronously [using SendIO() and WaitIO()]
OR Synchronously using DoIO().

If anyone's interested, I've got a set of handy-dandy routines for using
the timer.device (which I wrote myself) which, among other things, allows
you to access and release the timer.device through a "master" time-request
and quickly (ie. little overhead) get(rid of) "slave" time-requests which
can be used while you haven't released the "master".
Essentially it is an extension of the timer.device examples in the RKM
which give you greater flexibility (you can use the same port for the
"master" and all its "slaves") or simplicity if you like (just one call
does a synchronous timer delay).

Jan "I'm putting together a library of my handy-dandy routines" Sven.
----------------------------------------------------------------
Happiness is being smart enough to know what not to worry about.
Mind like parachute  -  function only when open!

Jan  (Jan, from Amsterdam) no-hyphen Sven  Trabandt
...!{allegro,ihnp4,decvax,pyramid}!utzoo!oscvax!jan