Re: Bugs in FIFO handling

   From: "Trever L. Adams" <[email protected]>


   Trever L. Adams wrote:
   > However, there are now other FIFO handling bugs. Using output=20
   > statements and other tests I am fairly certain these are in crm and=20
   > not the Linux Kernel (kernel-2.6.27.5-117.fc10.x86_64). Again, this is =

   > a dual core Athlon 64 machine with 4 gigabytes of memory.
   >
   > CRM on reading a FIFO, if the data comes too quickly loses data (input =

   > <byline>). Lines are always complete, but some lines are lost.

   Hello Everyone and Joyous Christmas and/or Hanukkah,

   I found the problem with the FIFOs. The problem is that I was reading=20
   from the FIFO, but not as a redirection to stdin. I was doing it like=20
   so: input <byline> [ :*:pipe: ] (:mydata:)

   This doesn't work, at least on Linux, because crm114 keeps closing
   the=20 file. Whenever it closes the file (every time the input
   completes, I=20 believe), the kernel drops whatever data is in the
   buffer.

   I do not think this is good as some programs may need multiple
   FIFOs. I=20 do not, so for now, I am just doing redirection and now
   my program works = perfectly.

Heh.  OK.

That may be a design bug then.  CRM114 by design has no such thing
as an "open file"; the only data structure supported is the overlapped
string.  (the reason to NOT change this is the future plan to allow
multiple data windows which are mapped to user-specified files, thus
allowing CRM114 to twiddle bytes right through the VM system; having
an "open file" data type complicates this significantly )

However, there is a workaround that you might want to try.

Note that subprocesses (created by "syscall") _do_ have durable
aspects.  You might be able to do a "tail -f" on your FIFO
and read the output of tail with a SYSCALL with the KEEP
flag set on, so the "tail -f" continues to operate on the
same fifo.

     - Bill Yerazunis


------------------------------------------------------------------------------