[Gs-devel] Block reading from standard input

[Igor V. Melichev]

Raph, Russel,

> From:   gs-devel-admin at ghostscript.com on behalf of Raph Levien
[raph at acm.org]
> Sent:   30 ??  2001 ?. 12:20
> To:     gs-devel at ghostscript.com; ghost at aladdin.com
> Subject:        [Gs-devel] Block reading from standard input

> Essentially, the problem is that "-" stdin reading is forced to be
> byte-at-a-time. This avoids deadlock problems in modes where
> PostScript commands are fed into stdin, then the responses are read
> out. The alternative "-_" command line option gives much better
> performance because reading happens in bigger blocks, but that will
> currently block when sending an incomplete block of data.

I'm sorry, I'm unable to understand, what "deadlock problems" actually is.
Here is my concern. Since we are technology company rather than
solution one, I suppose that GS is platform-independent DLL.

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.

Then, I don't see reason for byte-by-byte access to streams.
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.

I didn't check how GS reacts for incomplete buffers - I'm sorry,
now I need to work on a different high priority problem.
If it cannot handle incomplete buffer without EOF,
this is only thing to be improved. I believe it is very simple.

> The main reason for the extremely slow performance as of 7.00 is that
> control passes all the way up to the toplevel every time input is
> needed. At once per byte, the overhead for that is significant.

Besides passing to top level, it interprets some PS procedures
defined in gs_init.ps, and performs .needstdin for each byte.
At least I can see this on Windows. This reduces the speed in hundreds
times.
I'm unable to understand, what is the purpose of this stuff.

> There are a number of possible solutions to this problem, including
> simply better documenting the difference between "-" and "-_" so that
> people won't run into it.

Use.htm says :

[beg quote]
The difference between "-" and "-_" is that "-" reads the input
one character at a time, which is useful for programs such as GSview
that generate input for Ghostscript dynamically and watch for some response,
w
hereas "-_" reads the input in blocks, which is more efficient for ordinary
(batch) execution.
[end quote]

If GSView uses a bad technique, GSView must be fixed.
We should not adopt our general purpose product to specific programming
style
of a single programmer. Also I don't see any pipes in GSView, so as I don't
see reason to mix deadlock problem with byte-by-byte access. These 2
problems
look absolutely independent.

> However, I'm not really happy with an easy
> to use mode of operation that has appalling performance. People
> (including potential Ghostscript customers) _will_ run into it.

Agree.

> From:   gs-devel-admin at ghostscript.com on behalf of Russell Lang
[gsview at ghostgum.com.au]
> Sent:   30 ??  2001 ?. 13:32
> To:     gs-devel at ghostscript.com
> Cc:     ghost at aladdin.com; Raph Levien
> Subject:        Re: [Gs-devel] Block reading from standard input

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

This was true with Windows 3.11 6 years ago, but now it is not.
Console application for Windows can use stdio without problem.
Windowed application can compile with stdio, but the operating system
provides null files for it. I guess, using 'spawn' one can
provide regular files or pipes rather than null.

> I do see that non-blocking reads will help with reading pipes,

Would you mind to explain please, how it helps ???

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

Igor.