From: Peter Olcott on
Named pipes seem like a really good form of IPO. I want to
know if they are bogged down with disk I/O, since they are
treated as files. Some operating systems actually implement
pipes as temporary files, so I know that this is possible.


From: Mark Hobley on
In comp.unix.programmer Peter Olcott <NoSpam(a)ocr4screen.com> wrote:
> Named pipes seem like a really good form of IPO. I want to
> know if they are bogged down with disk I/O, since they are
> treated as files. Some operating systems actually implement
> pipes as temporary files, so I know that this is possible.

No. The file acts as a pointer (a bit like a device file). Inputs and outputs
are connected together and there is no intermediate write to disk.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Peter Olcott on

"Mark Hobley" <markhobley(a)hotpop.donottypethisbit.com> wrote
in message news:83hk87-45a.ln1(a)neptune.markhobley.yi.org...
> In comp.unix.programmer Peter Olcott
> <NoSpam(a)ocr4screen.com> wrote:
>> Named pipes seem like a really good form of IPO. I want
>> to
>> know if they are bogged down with disk I/O, since they
>> are
>> treated as files. Some operating systems actually
>> implement
>> pipes as temporary files, so I know that this is
>> possible.
>
> No. The file acts as a pointer (a bit like a device file).
> Inputs and outputs
> are connected together and there is no intermediate write
> to disk.
>
> Mark.
>
> --
> Mark Hobley
> Linux User: #370818 http://markhobley.yi.org/
>

How is the receiving end informed that here is something to
receive?


From: David Given on
On 03/04/10 21:56, Peter Olcott wrote:
[...]
> How is the receiving end informed that here is something to
> receive?

The receiving end has a file descriptor open on the pipe, and so it just
becomes readable. So any blocked read() will return, select() or poll()
will see it as readable, etc. The API should be identical to any other
stream-based file descriptor, such as a character device or socket.

That said, most Unixes have at least *some* bugs where all these things
behave slightly differently. I have vague memories of having to use
socketpair() instead of pipe() to connect two processes together because
some Linux kernels didn't do SIGIO notification properly, but that was
some years back now.

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "In the beginning was the word.
│ And the word was: Content-type: text/plain" --- Unknown sage
From: Peter Olcott on

"David Given" <dg(a)cowlark.com> wrote in message
news:hp8c81$kuv$1(a)news.eternal-september.org...
> On 03/04/10 21:56, Peter Olcott wrote:
> [...]
>> How is the receiving end informed that here is something
>> to
>> receive?
>
> The receiving end has a file descriptor open on the pipe,
> and so it just
> becomes readable. So any blocked read() will return,
> select() or poll()
> will see it as readable, etc. The API should be identical
> to any other
> stream-based file descriptor, such as a character device
> or socket.

So then it is not very good for event driven operations?
What I am looking for is some sort of callback mechanism
that can notify me when input is available.

>
> That said, most Unixes have at least *some* bugs where all
> these things
> behave slightly differently. I have vague memories of
> having to use
> socketpair() instead of pipe() to connect two processes
> together because
> some Linux kernels didn't do SIGIO notification properly,
> but that was
> some years back now.
>
> --
> ???? dg(a)cowlark.com ????? http://www.cowlark.com ?????
> ?
> ? "In the beginning was the word.
> ? And the word was: Content-type: text/plain" --- Unknown
> sage