Hi folks,
I'm working on a port of FreeBSD pipe implementation to NetBSD. So far,
the results are pretty owesame, the new pipes are significantly faster
than the old socketpair-based ones. Good work!

However, I found couple of things I don't quite understand and would
like to clarify if this is how things are supposed to work or if
I'm consfused :)

1) SIGIO for O_ASYNC reader, sync writer
   I made a test program which makes a pipe, sets owner of the read end,
   setup signal handler for SIGIO and switches the read end to
   O_NONBLOCK|O_ASYNC mode. Program forks,
   child makes sync write to the write (synchronous) end of pipe.
   When parents loops calling read() on the read end until it succeeds.
   However, I found out the parent gets SIGIO for each read(2) attempt.

This behaviour seems to be due to last couple of lines of pipe_read():

        if ((rpipe->pipe_buffer.size - rpipe->pipe_buffer.cnt) >= PIPE_BUF)
                pipeselwakeup(rpipe);

This condition is commonly true if the reader is polling for input. The code
should signal the writer, not the reader - it doesn't make sense to
signal possibility of writing more data to the reader itself.
IMHO the code should be like:

        if ((rpipe->pipe_buffer.size - rpipe->pipe_buffer.cnt) >= PIPE_BUF) {
                struct pipe *wpipe = rpipe->pipe_peer;
                if (wpipe)
                        pipeselwakeup(wpipe);
        }

Also, the code could possibly only call the pipeselwakeup() if anything
was actually read from the pipe previously (or, even better, only once
since last write(2)), to avoid sending SIGIO's to the writer if the
the reader found the pipe empty.

2) direct write - first uio only
  FreeBSD direct write code seems to handle only first uio buffer,
  so e.g. writev(2) with multiple buffers doesn't write all data
  at once.  This is valid behaviour (return short write and expect
  writer to update itself and try again with rest), I'd like just
  to ensure I read the code correctly.

3) direct write - loses for huge buffers?
  It seems pipe_build_write_buffer() tries to fault all the address space
  specified by uio. However, pipe_map.ms[] has only (BIG_PIPE_SIZE/PAGE_SIZE+1)
  members, so this seems to lose if the covered address space (size of
  buffer passed to write(2)) is > 64+4=68KB. Also, the code
  which calls pmap_qenter() thinks the buffer size is
  wpipe->pipe_buffer.size + PAGE_SIZE maximum. Do I read the code correctly,
  or is there anything I miss? The current port to NetBSD doesn't use
  this particular piece of code (the difference between FreeBSD VM and UVM
  is too big), but it's something I encountered and would like to understand :)
  
Thanks for you cooperation :)

Jaromir

P.S. Please CC: me, I'm not on the list
-- 
Jaromir Dolecek <[EMAIL PROTECTED]>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to