Your right of course....

Actually I was using the Print Spooler as an example, and it predates DOS
by a wide margin. IBM mainframes used a similar task as did digitals minis
and so on. In fact linux actually creates a "spooler" directory for each
users account.

To point out that in ONE implimentation it uses an interrupt, is to ignore
the fact that in SOME of these implimentations it might not have, and as a
"BACKGROUND" task, it certainly didn't need to, if the system is based on
a cooperative sequencing algorythm.

Interrupts were not all that prevalent in early computers, and I beleieve
that spoolers were found necessary, long before interrupts became derigor.
After all, if you are running a task that takes a long time, you have to
have SOME way of switching back and forth between it and your main tasks.

It is my guess that SPOOLERS PREDATE either dos or interrupts by a WIDE
margin. They are sort of the flip side of POLLING, another technique that
has fallen by the wayside since the implimentation of interrupts.

I hope this clarifies to some extent the nature of the difference between
an algorythm that is "Generally Interrupt driven" and an algorythm that is
"Interrupt dependent".

                                GREY

GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Mon, 17 May 1999, Dr. Imre Bartfai wrote:

> Hi,
> only as a small remark: the DOS print spooler (I do not know whether
> another ones...) is working on an interrupt basis, as the printer tells
> with an IT if the data has been printed, so asks for new data. There is no
> time slicing.
> Imre
>
>
> On Sat, 15 May 1999, Graeme Smith wrote:
>
> > I have been working on such a machine....
> >
> > As near as I can tell the only real benefit an interrupt gives you, is
> > the ability to do instantaneous changes in context. You can get much the
> > same effect without an interrupt simply by planning your code so that it
> > always takes the same amount of time, to execute, for each portion of a
> > task you have it do.
> >
> > Instead of getting instantaneous service, you get essentially, a known
> > delay time between the mainline code, and the service routine. If you use
> > a cooperative system that leaves the processor in a known state, or
> > dedicate some registers to saving the context for each task, you can
> > manage less instantaneous but certainly timely effects that would be hard
> > to tell from an interrupt.
> >
> > The absolute minimum multi-tasking system, for such a processor would of
> > course be the simple round robin sequencer, which gives each task its own
> > time slice. By designating one task as a foreground task, and the other as
> > a background task, you can signal the need for a supporting background
> > task to be launched from your main application in the foreground.
> >
> > A perfect example of this, is spooling, which is a background task that
> > runs the printer, while the foreground tasks, are ongoing.
> >
> > Each time the spooling task is called, it sends another small string of
> > characters to the printer, then returns control to the main task. The main
> > task, runs for a period, and then returns control to the sequencer, which
> > can call the spooler, or another background task, such as garbage clean
> > up, to take care of the print buffer after the data has been printed.
> >
> > In such a two task system control passes back and forth between the tasks
> > in an oscillating effect, advancing both of them just as easily as one.
> >
> > The main difference between this and an interrupt driven system, that does
> > two tasks at the same time, lies in the design of the code to be packaged
> > in standard length snippets, rather than running any code at all, and
> > using the interrupt to switch contexts.
> >
> > Such programs where the coding co-operates, is called co-operative
> > multi-tasking rather than standard multi-tasking, and requires a bit more
> > sophistication of the programmer, in order to make more efficient.
> >
> >                                         GREY
> >
> > GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
> > YMCA Edmonton
> >
> > Address has changed with little warning!
> > (I moved across the hall! :) )
> >
> > Email will remain constant... at least for now.
> >
> >
> > On Mon, 10 May 1999, Seyler Jean-Yves wrote:
> >
> > >                 Hello all PICers,
> > >
> > >         Some time ago, there has been a discussion about multitasking and
> > > solutions have been proposed with interrupts ...
> > > Does any of you has an idea of a multitask kernel (2 tasks should cover
> > > most applications) without usong interrupt facilities in order to be put
> > > on a PIC 12C509 for example ?
> > >
> > > Thanks
> > >
> >
> >
>