[Gs-devel] Block reading from standard input

[Russell Lang]

Raph,

> Thus, I am asking Peter and Russell the following questions:

I don't think these are the correct questions.  I'll answer them, 
then suggest an alternative.

> * Does it make sense to use read() for stdin?
Yes, in that Ghostscript already provides stream buffering.  We don't 
need both fread and Ghostscript streams implementing buffering.

> * Are all stdin reads through the e_NeedStdin callback (when STDIO_
>   IMPLEMENTATION=c, anyway),
Yes.  
> or is it possible for some of them to go through the standard file logic?
No.  You don't want to mix them.  For a DLL/shared object build, we 
don't even use standard file logic if the caller provides stdio 
callback functions.  All standard file code access is done by the 
caller, not by Ghostscript. The only exception to this is that 
standard output can be written from the device drivers when "-
sOutputFile=-" is used.

For Window graphical executables running in a non-debugging
environment, stdio is NOT available.

> * Do we really need to avoid blocking stdin reads? If gs is being
>   invoked through the DLL interface, then setting up actual pipes for
>   stdin and stdout seems unnecessary - it should be possible to pass
>   data in and out directly.
The problem is reading in small blocks (one character), not blocking.
I do see that non-blocking reads will help with reading pipes, 
but for platform independence I don't want to see pipes or non-
blocking I/O in the stdio stream code.  Let the caller implement
this if needed.

> * Why do we have both FILE_IMPLEMENTATION=fd and =stdio, especially
>   when the former seems to have bit-rotted substantially?
Don't know.  Peter will need to answer that.

In my opinion, we need one implementation of the Postscript stdio  
streams not three.  

The current  STDIO_IMPLEMENTATION=c is far too slow.  It is a neat 
idea, but the overheads in calling out of the interpreter for each 
character kill it.
When operating interactively this isn't a problem.
When piping input to Ghostscript this is a problem.  Performance is 
acceptable when using "-_", but most people will probably use "-" and 
then complain about the performance, without finding "-_".  Ghostview 
and gv use "-" since they need to one page at a time to Ghostscript.
This isn't a problem in GSview, which doesn't use stdin and instead 
uses gsapi_run_continue() with larger blocks of data.

As an aside, Peter did suggest that stdio callouts could return back 
to the caller.  I didn't implement this idea and instead used 
callback functions from just outside the main interpreter loop.
This was because gs_main_init2() runs the interpreter and 
so it would need to support callouts.  This would require a massive 
rewrite of gs_main_init_with_args()/swproc().

My preferred solution is to call a callback function directly from 
stdio stream code.  This is the fastest solution.  The difficulty is 
in implementing this while retaining the architectural separation
of the stream code from the interpreter.

There are three layers of interest.
1. Interpreter instance. iminst.h. The callback function pointers are 
currently stored here.  Pointers to the C stdio streams are
stored here, but should be removed.
2. Context state.  icstate.h. References to the PostScript stdio 
streams are stored here.
3. Streams.  This is where the action should be.

Streams have references to neither the context nor the interpreter 
instance.  Only when the stdio stream is opened is the context 
pointer temporarily stored in the stream so that the stream reference 
can be obtained from the context state.
The codes is marked with lots of warnings about this.

To make the callbacks work, we need to do pass the callback function 
pointer and caller handle down to the stream.  The stream can then 
call the callback function directly.  If a callback function is not 
provided by the caller, the interpreter should install callback 
functions which use C stdio (read() etc).

We also need the ability for the the caller to return an error code 
to the stdio callback function to force the interpreter to return.



Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/