infinite loops -- waiting for some event

[Andrej Hocevar]

Hello,
what is the best way of solving cases where one has to wait
(forever, until killed or instructed otherwise) for some event to
occur? E.g., wait for data, monitoring a file? In fact, that task is
not that difficult, but takes over the CPU if the infinite loop
lacks sleep(). I've always thought using this method was somehow
inferior but then found out that even utilities like tail(1) (on
Linux) use it. Or on another occasion, if one uses curses (UNIX
again), which will most likely include an infinite loop, with the
nodelay(...) option turned on. Obviously, there must be a solution to
such cases: with nodelay() turned off, the infinite loop doesn't need
sleep(). Is a daemon, thus a system-dependant solution, the best way
to go or is it unconnected with such a task?

What is the solution behind these methods?

Thanks,

andrej
--
echo ${girl_name} > /etc/dumpdates

[Barry Margolin]

In article <slrnbh8irl.r2.drejcica@sonet.utopija.linux>,
Andrej Hocevar <drejcica@volja.net> wrote:

>Hello,
>what is the best way of solving cases where one has to wait
>(forever, until killed or instructed otherwise) for some event to
>occur? E.g., wait for data, monitoring a file? In fact, that task is
>not that difficult, but takes over the CPU if the infinite loop
>lacks sleep(). I've always thought using this method was somehow
>inferior but then found out that even utilities like tail(1) (on
>Linux) use it. Or on another occasion, if one uses curses (UNIX
>again), which will most likely include an infinite loop, with the
>nodelay(...) option turned on. Obviously, there must be a solution to
>such cases: with nodelay() turned off, the infinite loop doesn't need
>sleep(). Is a daemon, thus a system-dependant solution, the best way
>to go or is it unconnected with such a task?

If the event you're waiting for is data from a device, you normally block
in read() or select() to wait for data to be available.

If you're monitoring an ordinary file, there's usually no alternative to an
infinite loop, and you should have a sleep() in it to keep from
monopolizing the system.

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[Gianni Mariani]

Andrej Hocevar wrote:

> Hello,
> what is the best way of solving cases where one has to wait
> (forever, until killed or instructed otherwise) for some event to
> occur? E.g., wait for data, monitoring a file? In fact, that task is
> not that difficult, but takes over the CPU if the infinite loop
> lacks sleep(). I've always thought using this method was somehow
> inferior but then found out that even utilities like tail(1) (on
> Linux) use it. Or on another occasion, if one uses curses (UNIX
> again), which will most likely include an infinite loop, with the
> nodelay(...) option turned on. Obviously, there must be a solution to
> such cases: with nodelay() turned off, the infinite loop doesn't need
> sleep(). Is a daemon, thus a system-dependant solution, the best way
> to go or is it unconnected with such a task?
>

select() and or poll() are the most common ways to do what you describe
on unix.

select and poll suffer scalability issues when you start dealing with
around several thousand or more file descritors and there are newer
techniques like /dev/kqueue or signals (SIGIO) and most recently and
probably the best technique yet is epoll on linux.

The problem you describe with curses I have solved with select and poll
but you need to be careful wrt buffering, i.e. data may not be available
from the kernel but may be sitting in an internal buffer and waiting on
I/O at that point would be bad because you'd rather finish processing
the remaining data in the buffer.

[Valentin Nechayev]

>>> Andrej Hocevar wrote:

AH> what is the best way of solving cases where one has to wait
AH> (forever, until killed or instructed otherwise) for some event to
AH> occur? E.g., wait for data, monitoring a file? In fact, that task is
AH> not that difficult, but takes over the CPU if the infinite loop
AH> lacks sleep(). I've always thought using this method was somehow
AH> inferior but then found out that even utilities like tail(1) (on
AH> Linux) use it. Or on another occasion, if one uses curses (UNIX
AH> again), which will most likely include an infinite loop, with the
AH> nodelay(...) option turned on. Obviously, there must be a solution to
AH> such cases: with nodelay() turned off, the infinite loop doesn't need
AH> sleep(). Is a daemon, thus a system-dependant solution, the best way
AH> to go or is it unconnected with such a task?

You can choose a event library from existing ones or write your own
implementation. They allow waiting for multiple events, organizing timer
lists, etc.


-netch-

[Nate Hill]

Andrej Hocevar wrote:

> Hello,
> what is the best way of solving cases where one has to wait
> (forever, until killed or instructed otherwise) for some event to
> occur? E.g., wait for data, monitoring a file? In fact, that task is
> not that difficult, but takes over the CPU if the infinite loop
> lacks sleep(). I've always thought using this method was somehow
> inferior but then found out that even utilities like tail(1) (on
> Linux) use it. Or on another occasion, if one uses curses (UNIX
> again), which will most likely include an infinite loop, with the
> nodelay(...) option turned on. Obviously, there must be a solution to
> such cases: with nodelay() turned off, the infinite loop doesn't need
> sleep(). Is a daemon, thus a system-dependant solution, the best way
> to go or is it unconnected with such a task?

While unrelated I have to point out that the only real solutions to infinite
loops must be done in kernel-land. Any feature that "blocks" is either
driven itself by an infinite loop or is a kernel feature. Of course, these
things are trivial in kernel space. For instance, most filesystem layers
implement some kind of queue for files being monitored and since they are
the ultimate authority on a files state they only need to notify these
monitors when the file changes.

--
Nate Hill <vugdeox@freeshell.org>