Do named pipes have disk I/O ?? [Unix Programming]

Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: Why can't I catch a SIGBUS on my Mac (when strlen(NULL) is used)?

From: Moi on 4 Apr 2010 08:53

On Sun, 04 Apr 2010 07:33:29 -0500, Peter Olcott wrote:

> So then are you saying that the previous respondent is wrong?
> I will only have at most two file descriptors that will be waited on.
>
> I really want to avoid checking to see if there is input available a
> billion times per second in a tight loop. The approach that I am
> considering is to check to see if input is available 100 times per
> second in a tight loop that sleeps for 10 ms using nanosleep().

Well: poll / select do not spin in a loop.
They only return if something happened, either
+ a fd becoming available
+ a timeout
+ or a signal.

100 requests / sec is not big enough to worry, IMO.
per request you would perform:
+ 1 select/poll
+ 1 read
+ 1 write
+ some real processing.

There are cases where you would not want to waste 3 systemcalls
per request. (that is what DS is trying to say)
If you have only one file descriptor to read, you can omit the
poll/ select and block on the read.

AvK

From: Moi on 4 Apr 2010 08:57

On Sun, 04 Apr 2010 07:27:53 -0500, Peter Olcott wrote:

> "Moi" <root(a)invalid.address.org> wrote in message
> news:981fe$4bb86a0b$5350c024$32454(a)cache100.multikabel.net...
>> On Sat, 03 Apr 2010 21:25:52 -0500, Peter Olcott wrote:
>>
>>> "Eric Sosman" <esosman(a)ieee-dot-org.invalid> wrote in message
>>> news:hp8flb$oa9$1(a)news.eternal-september.org...
>>>> On 4/3/2010 6:10 PM, Peter Olcott wrote:

>> Blocking does not cost CPU. Your process is just stuck in a systemcall
>> that has not returned yet.
>> So it will cost you a thread. (which has nothing useful to do anyway)
>>
>>
> That would be OK. So I place the read in an infinite loop, and when
> there is nothing to read, then the read never returns so it does not
> cost CPU.

Yes. compare it to:

while((ch=getc(stdin)) != eof)
{
...
}

That does not burn CPU. It just blocks until you happen to hit
a key (or a newline ;-)

AvK

From: Jens Thoms Toerring on 4 Apr 2010 09:15

In comp.unix.programmer Peter Olcott <NoSpam(a)ocr4screen.com> wrote:
> Yeah so now that I understand how pipes work a little
> better, and that the function named poll() is a misnomer

It's only a misnomer when you take the name to indicate how
it's implemented but not when you consider what it does: it
produces the same result as traditional polling, i.e. tells
you that something about the file changed - just without all
the overhead;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de

From: Mark Hobley on 4 Apr 2010 12:45

In comp.os.linux.development.apps Peter Olcott <NoSpam(a)ocr4screen.com> wrote:

> So it is in an infinite loop eating up all of the CPU time
> only when there are no requests to process?

No. The process will sleep until input is available. When input becomes
available, the kernel will wake up the process.

Mark.

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

From: David Schwartz on 5 Apr 2010 02:43

On Apr 4, 5:33 am, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:

> So then are you saying that the previous respondent is
> wrong?

Not wrong, just incomplete.

> I will only have at most two file descriptors that will be
> waited on.

Then your best bet is either to have two threads, one blocking in
'read' on each file descriptor (blocking sockets) or one thread
blocking in 'poll' or 'select' (non-blocking sockets).

> I really want to avoid checking to see if there is input
> available a billion times per second in a tight loop. The
> approach that I am considering is to check to see if input
> is available 100 times per second in a tight loop that
> sleeps for 10 ms using nanosleep().

There is no need to do that.

DS