Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash

[Zac Medico]

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 <vapier@g.o> 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