[Gs-devel] Block reading from standard input

[Igor V. Melichev]

Russel,

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

> I agree.  But Ghostscript is available as an executable so it is both
> a client and a library.

Please don't mix different things. There exists Ghostscript library.
There exists multiple clients which call the library.
For instance, gswin32 is a client. If you build
an application linking both client and the library within a single .exe,
it is not a reason to say, that Ghostscript is executable.
The application is. As well as if I link Ghostscript library
together with OLE server or Java bean, it is not a reason to say,
that Ghostscript is OLE server or Java bean.

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

Pipes are only useful for communication between threads.
Run the producer, the consumer and the library in different threads.
No need for byte-by-byte access.

Of cause, if you want to synchronize *only* with pipes (i.e. without using
synchronization primitives different that pipes),
the transfer graph must have no loops.

But if you want to connect a thread through a pipe with itself
(directly or via Ghostscript), you do need something more complicated,
rather than a procedure for reading/writing data from/to single pipe
synchronously.
You need either asynchronous output or asynchronous input.
Otherwise the tread goes to deadlock immediately.
Again, no need for byte-by-byte access.

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

This is exactly what I propose : do not wait until buffer is completely
full.

> No problem in GSview.  The problem isn't specific to gswin32 - it is
> present on all platforms that use callouts.

Well, now I see the problem. Ghostscript wants to so many bytes
as buffer can handle just to minimise its internal callouts.
Sometimes client cannot supply so many data at moment, and wants
Ghostscript to process only available data. This is conflict.
To resolve it, we need a signal, which informs Ghostscript
that it should process incomplete buffer right now.
It is not important, whether it is callback or callout.
Just pass the signal somehow.

For existing code, this requires to introduce new state
SUSPENDC for end_status of stream_s.
Yes, this brings more complexity to stream.c .
But I believe, this is only way to resolve the conflict
in the existing architecture. Only alternative is to replace
I/O callouts with callbacks, as I proposed before.

Igor.