[PATCH fifo 0/2] Add support for duplex FIFOs

[Achim Gratz]

Ken Brown writes:
> I found a bug in my fhandler_fifo::raw_write code that could explain the 
> problem.  The call to NtWriteFile in that function always returns immediately 
> because the Windows named pipe underlying the FIFO is non-blocking.  If it can't 
> write because the pipe buffer is full, raw_write returns -1 with error EAGAIN. 
> That's wrong if the FIFO was opened in blocking mode.

Sounds like a clue or at least it doesn#t contradict what I'm seeing.  I
have no idea if that explains all the problems I'm seeing, I'll describe
them in more detail below.

> I'll have to think about how to best handle this.  I think I might be able to 
> imitate what's done in fhandler_socket_unix::sendmsg in the topic/af_unix branch.

OK, a bit more info: The whole thing runs from a perl script (actually a
module) that opens pipes to gnuplot and ghostscript.  This code is
_really_ old and has seen a lot of Cygwin releases, so it has options to
either use temporary files, named pipes aka FIFO or direct pipes.  Using
temporary files serializes the execution and using a pipe chain is
_really_ slow (like a hundred times, which is mostly tied up in system
for a reason that I don't understand), so using FIFO is the default.
Your new FIFO code increases the system time by about a factor of 10 in
my tests, btw.

The error with the FIFO to gnuplot is that some data that was written
into the FIFO already doesn't show up at the reader end, but later data
written into it does.  Here somewhere around a few kiB go missing and
gnuplot runs into a syntax error when it happens.

If I run gnuplot through a plain pipe to skip that error, but keep
ghostscript on FIFO, then it _almost_ works correctly.  Except that once
gnuplot has finished writing to the FIFO I need to write the bookmarks
dictionary before closing the output file and that write again
overwrites data that should already have been present at the other side.
I've played a bit with putting in flushes and sleeps and there's between
one to three pages at the end of the document that go missing, so again
a handful of KiB.

So either of these two errors indiqcates problems with synchronizing the
reader/writer side, which makes some of the written data disappear on
the receiving end of the FIFO.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds