Re: printer server

[robert@par.univie.ac.at (Robert Mayer - Student) writes:]

>The server is implemented in a very simple way: It receives an FS_WRITE message,
>then it prints the data in a polling loop, and finally returns to the main
>message loop. That way an abort message makes no sense (the server doesn't
>receive messages while an I/O is in progress) and is simply ignored. I suppose
>a user would not use the printer server directly, but instead one would have
>a spooler server (more about spooler servers below) which feeds the printer
>server in small chunks, and to abort a print job the spooler server simply
>stops feeding chunks. Is this good enough ? Any opinions ?

You are using synchronous I/O, which is good (usually) for things like
disks. Its problem is that you can hang a user if your printer stops
responding for a while.

>The handling of the parallel port at the hardware level is implemented as a
>C++ class (or rather as a struct, which is really a class without constructor/
>destructor). Any reason not to use C++ in VSTa ?

All of VSTa is written in C currently; each time you add a new language to
the base OS source, you make it incrementally harder for other people to
build it. It also incrementally steals my time, since each new run-time
environment will generate a new set of questions, and a new set of things I
have to check from time to time. Thus, I am reluctant to add a new language
without a compelling reason.

Please, no computer language flame wars here.

>Some thoughts about a spooler server:
>A spooler server could look like several directories, representing different
>queues. To print a file, you 'cp' it to the appropriate directory, to remove
>or abort it, you 'rm' it. 'rm' should also be possible if the printing was
>already in progress. If a file is printed successfully, it simply disappears.
>Stat fields of these files could show ranking order and stuff like this. The
>spooled data could be stored in an mmap()'ed file or in (a) regular file(s)
>in a spooling directory, so print jobs would not be lost due to a
>system/spooler/printer crash.
>A spooling server implemented like this would seem very easy to use, what do
>you think ?

Well, a synchronous server reduces the benefits of this approach a bit,
since you can just as easily get hung queueing data as writing it to the
printer itself. To make it really friendly/safe, I suspect you'll want a
pair of threads, one watching the incoming queue, and another taking
successive jobs and feeding them out to the printer.

>Probably the most important question: Is it a good idea to add a sophisticated
>printing/spooling system at this time ? Since VSTa internals are still
>subject to changes, it could add a considerable amount of maintenance.

The internals are subject to change, but I think the API has stabilized. I
think it would be a great idea! :-)

                                                Andy
Received on Thu Mar 17 08:32:15 1994