On 06/02/2012 06:04 PM, Zac Medico wrote: > On 06/02/2012 04:47 PM, Brian Harring wrote: >> On Sat, Jun 02, 2012 at 03:50:06PM -0700, Zac Medico wrote: >>> On 06/02/2012 02:31 PM, Micha?? G??rny wrote: >>>> On Sat, 2 Jun 2012 15:54:03 -0400 >>>> Mike Frysinger <vap...@gentoo.org> wrote: >>>> >>>>> # @FUNCTION: redirect_alloc_fd >>>>> # @USAGE: <var> <file> [redirection] >>>>> # @DESCRIPTION: >>>> >>>> (...and a lot of code) >>>> >>>> I may be wrong but wouldn't it be simpler to just stick with a named >>>> pipe here? Well, at first glance you wouldn't be able to read exactly >>>> one result at a time but is it actually useful? >>> >>> I'm pretty sure that the pipe has remain constantly open in read mode >>> (which can only be done by assigning it a file descriptor). Otherwise, >>> there's a race condition that can occur, where a write is lost because >>> it's written just before the reader closes the pipe. >> >> There isn't a race; write side, it'll block once it exceeds pipe buf >> size; read side, bash's read functionality is explicitly byte by byte >> reads to avoid consuming data it doesn't need. > > I've created a little test case and it seems you're right that nothing > is lost.
Actually, I forgot the mkfifo call, so it was writing a regular file. With it the fifo, the write appears to be lost, as I originally suspected. -- Thanks, Zac
named_pipe_check_for_lost_write.sh
Description: application/shellscript
