[Gs-devel] Block reading from standard input

[Russell Lang]

Igor wrote:
> GS code doesn't use standard C streams stdin, stdout, stderr.
> It calls client's callout instead. If a client associates
> stdin, stdout, stderr with these callouts, it's client's problem
> how to resolve deadlocks related to pipes.
I agree.  But Ghostscript is available as an executable so it is both 
a client and a library.  

> Then, I don't see reason for byte-by-byte access to streams.
Ghostview/gv need this, as does any program that opens a pipe
to Ghostscript stdin, writes PostScript to the pipe and waits for
a response.  GSview does not do this so is not affected by
the slow callouts.

> Why 1 byte is better than n bytes ? If client cannot provide
> enough bytes to fill buffer, let it fill so many as it can and
> pass counter to GS. GS should not treat incomplete buffer
> as EOF, and that's all. If client cannot provide even a single
> byte, it must not resume GS or resume it with EOF.
Agreed.

> > I do see that non-blocking reads will help with reading pipes,
> Would you mind to explain please, how it helps ???
To make programs like Ghostview/gv work, Ghostscript reads stdin one 
byte at a time.  If using callouts, the performance is terrible.
If you changed Ghostscript to always read multiple bytes at a time 
(to minimise the callout penalty), then you would have to change 
Ghostscript to use non-blocking reads so it will return with all the 
bytes that are currently available, rather than waiting until the 
buffer is completely full.  If you used blocking reads, Ghostview/gv
wouldn't work.

> > 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.
> 
> Very good! Just fix GSView and gswin32, and the problem is closed.
No problem in GSview.  The problem isn't specific to gswin32 - it is 
present on all platforms that use callouts.  This includes the Linux 
shared object.  Rather than having two methods for stdin (callouts 
and direct C streams), I would prefer that there is only one method 
available (callouts or a direct callback).  Whenever I proposed 
changes to Ghostscript, Peter always insisted on doing it in a common 
platform independent way.  I've learnt the wisdom of this - if it 
breaks on one platform it breaks on all.  You minimise platform 
dependent bugs.



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