1 |
On 06/02/2012 06:04 PM, Zac Medico wrote: |
2 |
> On 06/02/2012 04:47 PM, Brian Harring wrote: |
3 |
>> On Sat, Jun 02, 2012 at 03:50:06PM -0700, Zac Medico wrote: |
4 |
>>> On 06/02/2012 02:31 PM, Micha?? G??rny wrote: |
5 |
>>>> On Sat, 2 Jun 2012 15:54:03 -0400 |
6 |
>>>> Mike Frysinger <vapier@g.o> wrote: |
7 |
>>>> |
8 |
>>>>> # @FUNCTION: redirect_alloc_fd |
9 |
>>>>> # @USAGE: <var> <file> [redirection] |
10 |
>>>>> # @DESCRIPTION: |
11 |
>>>> |
12 |
>>>> (...and a lot of code) |
13 |
>>>> |
14 |
>>>> I may be wrong but wouldn't it be simpler to just stick with a named |
15 |
>>>> pipe here? Well, at first glance you wouldn't be able to read exactly |
16 |
>>>> one result at a time but is it actually useful? |
17 |
>>> |
18 |
>>> I'm pretty sure that the pipe has remain constantly open in read mode |
19 |
>>> (which can only be done by assigning it a file descriptor). Otherwise, |
20 |
>>> there's a race condition that can occur, where a write is lost because |
21 |
>>> it's written just before the reader closes the pipe. |
22 |
>> |
23 |
>> There isn't a race; write side, it'll block once it exceeds pipe buf |
24 |
>> size; read side, bash's read functionality is explicitly byte by byte |
25 |
>> reads to avoid consuming data it doesn't need. |
26 |
> |
27 |
> I've created a little test case and it seems you're right that nothing |
28 |
> is lost. |
29 |
|
30 |
Actually, I forgot the mkfifo call, so it was writing a regular file. |
31 |
With it the fifo, the write appears to be lost, as I originally suspected. |
32 |
-- |
33 |
Thanks, |
34 |
Zac |