Re: printer server

[Andrew Valencia <vandys@cisco.com> writes:]
> 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.
>
Error handling is not really implemented yet, but I had the following in mind:
If the printer doesn't respond, I would simply log an error (currently printf,
later the new syslog() ?), return EIO and discard the data. Discarding
the data should not be a problem, since the spooling server keeps the original
until successful completion (and a user that 'cp's a file to /dev/printer or
whatever should do the same). The (obvious) idea behind this is: keep the
hardware dependent printer server as simple as possible, and put the fancy
stuff into a hardware independent spooler server.

[ reasons why not to use C++ right now deleted ]

Okay, I can easily change it into C.

> >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.
>

I agree, a good spooler server should use a separate thread to talk to the
printer *server* , which could still be synchronous and thus simple.

> >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
>

I can send you, Andy, the printer server once it is finished (and converted
to C :-( ), but I didn't even start to code a spooler server.

Robert
Received on Thu Mar 17 09:45:49 1994