I'm following some advices given here for the gs JobServer mode: http://bugs.ghostscript.com/show_bug.cgi?id=691038#c5 http://bugs.ghostscript.com/show_bug.cgi?id=690352#c18 in particular I created two fifo filesystem pipes: mkfifo togs mkfifo fromgs and launched Ghostscript: gs -dNOPAUSE -dEPSCrop -sDEVICE=pngalpha -r300 -dJOBSERVER next I did in separated processes: cat some.eps >togs cat fromgs and in gs jobserver mode: GS><< /OutputFile (fromgs) >> setpagedevice GS>.locksafe GS>(togs) run After quiting the input pipe (togs) I don't see a close on (fromgs). I expected http://www.adobe.com/products/postscript/pdfs/PLRM.pdf I expected the behavior described in Postscript Reference Manual p.70 (pdf p.84): "7. Close the standard input and output files, transmitting an end-of-file indication over the communication channel." But maybe I'm not sending the correct commands or misunderstanding something.
Output file is closed when the output device is closed. For instance, this can happen when the output device goes out of scope and is closed by restore. So the server loop can be modified to install a new device. The base device should be different from the device used in the loop. gs -sDEVICE=nullpage ... (pngalpha) selectdevice <</OutputFile (foo.png)>>setpagedevice % run the file here <04> cvx exec % or just delimit the jobs with 0x04 I don't have a strong opinion about PLRM conformance of our device implementation and would appreciate Ray's comments on the problem.
Ghostscript does not close the stdio files. It expects the OS to do this when the process exits. As far as the PLRM job server action, we don't close stdin or stdout because then we would not be able to use those files anymore. There really isn't any way to "transmit and end of file" to stdout or stderr. If you wanted to implement something like TBCP on stdout and stderr, with the complementary protocol in whatever is reading 'fromgs', then you could send and out-of-band logical 'EOF' without actually closing stdout so ghostscript could continue using stdout for the next job received from stdin. After processing from stdin, we do the 'restore', then do the top part of the server loop, continuing to use the stdio files. If you cause Ghostscript to exit, then (presumably) the OS will close the stdout and stderr, but that isn't our concern.
Closing the bug for the lack of follow-up and the reasons stated above.