Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o
Cc: Brian Harring <ferringb@×××××.com>
Subject: Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash
Date: Sun, 03 Jun 2012 01:05:54
Message-Id: 4FCAB829.2000606@gentoo.org
In Reply to: Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash by Brian Harring
1 On 06/02/2012 04:47 PM, Brian Harring wrote:
2 > On Sat, Jun 02, 2012 at 03:50:06PM -0700, Zac Medico wrote:
3 >> On 06/02/2012 02:31 PM, Micha?? G??rny wrote:
4 >>> On Sat, 2 Jun 2012 15:54:03 -0400
5 >>> Mike Frysinger <vapier@g.o> wrote:
6 >>>
7 >>>> # @FUNCTION: redirect_alloc_fd
8 >>>> # @USAGE: <var> <file> [redirection]
9 >>>> # @DESCRIPTION:
10 >>>
11 >>> (...and a lot of code)
12 >>>
13 >>> I may be wrong but wouldn't it be simpler to just stick with a named
14 >>> pipe here? Well, at first glance you wouldn't be able to read exactly
15 >>> one result at a time but is it actually useful?
16 >>
17 >> I'm pretty sure that the pipe has remain constantly open in read mode
18 >> (which can only be done by assigning it a file descriptor). Otherwise,
19 >> there's a race condition that can occur, where a write is lost because
20 >> it's written just before the reader closes the pipe.
21 >
22 > There isn't a race; write side, it'll block once it exceeds pipe buf
23 > size; read side, bash's read functionality is explicitly byte by byte
24 > reads to avoid consuming data it doesn't need.
25
26 I've created a little test case and it seems you're right that nothing
27 is lost.
28 --
29 Thanks,
30 Zac

Attachments

File name MIME type
named_pipe_check_for_lost_write.sh application/x-shellscript

Replies