🚀 go-pugleaf

In article <8905221304.AA14261@decwrl.dec.com> batcheldern@hannah.dec.com (Ned Batchelder, PostScript Eng.) writes:
>Another reason is for accurate notification of job completion.  Even if we
>could assume that shipping the data to the printer guaranteed that the job
>would complete, when would it complete?  By having an explicit handshake
>between the spooler and the printer, the spooler knows that, in fact, the
>job is completed, and if the user gets up from his desk and walks over to
>the printer, he will be able to pick the job up and walk away.

This is a worthy goal, but it isn't always true, unfortunately.  The
end-of-file (it isn't always a ^D) is echoed by the printer when an EOF
is read from the input stream. Usually, this corresponds to the end of
the job, since the interpreter has finished executing all the tokens it
has received, and wants more.  However, there are several circumstances
under which a printer can consume the EOF, say "thank you" (by echoing
another EOF), but not finish processing the job for quite some time.
One of these is a job that reads data from the end of file itself, in
which case it is not the scanner that hits EOF, it is, say, the
"readhexstring" operator.  If the program then turns around to process
the data, it may be quite some time before it finishes, in an extreme
case.  It can also generate ERRORS even after the data connection has
been broken with the host, which can be difficult deal with.  Another
instance (I think) is when the EOF follows the last token directly,
without intervening white space, as in:

	showpage^D

instead of

	showpage
	^D

The EOF then delimits the token, and is seen by the scanner while
recognizing the name.  I think the EOF is echoed then, by the scanner,
rather than after the "showpage" name has been executed, but I'm not
sure of it.  In any case, it is an implementation detail.

To echo what Ned Batchelder said, envision a scenario where you have a
2k communications buffer (very common), and you are sending a 1k file.
The whole file will fit into the buffer (including the EOF), and
theoretically you could break the connection then or send another file
on its heels.  But you may, instead, want to wait for the EOF to be
echoed back to indicate that the job is done, or to detect an error and
potentially retransmit the job instead of transmitting the next one.

One way to think of it is that it is not a printer at all, but another
computer connected through some communications protocol.  The protocol
usually has (and should have) some basic handshaking to determine when
a file has been completely received, and that's what the echoing of EOF
does.  The "spooler" is not a traditional spooler, because it is not
dealing with a dumb printer.  It is really a communications program, a
printer monitor, and lots of other things.

Glenn Reid
Adobe Systems