Home > Archive > Unix Programming > December 2006 > timeout problems while using select with pipes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
timeout problems while using select with pipes
|
|
|
| In my C program, a parent process reads data off from a pipe that is
written to by its child. In the parent process, I use select operations
executed in an infinite loop to check if there is data on the pipe to
be read. The child process generates data and writes it to the pipe.
The issue I am having is that select ALWAYS fails to recognize that
there is any data available if I set a timeout of less than 10,000
microsec. If I do set a shorter timeout, select always returns
indicating that there is not data, which is not true since I know the
child has executed (based on printf's). Setting larger timeouts (>
50000 micros.) solves this problem. Also when I step through the
program using a debugger, irrespective of the timeouts it works fine.
I am running Linux kernel ver. 2.6.9
Is there a known issue related to this behaviour?
How can I debug something like this without using a debugger (which
makes the problem go away)?
| |
| Barry Margolin 2006-12-22, 10:04 pm |
| In article <1166816672.646553.260570@79g2000cws.googlegroups.com>,
"bnp" <bpisupat@cs.indiana.edu> wrote:
> In my C program, a parent process reads data off from a pipe that is
> written to by its child. In the parent process, I use select operations
> executed in an infinite loop to check if there is data on the pipe to
> be read. The child process generates data and writes it to the pipe.
>
> The issue I am having is that select ALWAYS fails to recognize that
> there is any data available if I set a timeout of less than 10,000
> microsec. If I do set a shorter timeout, select always returns
> indicating that there is not data, which is not true since I know the
> child has executed (based on printf's). Setting larger timeouts (>
> 50000 micros.) solves this problem. Also when I step through the
> program using a debugger, irrespective of the timeouts it works fine.
>
> I am running Linux kernel ver. 2.6.9
>
> Is there a known issue related to this behaviour?
> How can I debug something like this without using a debugger (which
> makes the problem go away)?
If you're using printf() in the child, its output is probably being
buffered. As a result, data will not be available in the parent as soon
as the child calls printf().
What happens if you disable buffering with setbuf() in the child?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
|
|
> What happens if you disable buffering with setbuf() in the child?
Buffering certainly was an issue (I should have thought of that). But
interestingly, using unbuffered writes to the pipes reduces the
minimum select timeout for seeing the 'right' behaviour to 1000 msec.
Setting the timeout to be anything less than this means that select
again fails to recognize that there is data available to be read.
Also 1000msec is the consistent number I see across different machines,
and even on a Solaris box.
|
|
|
|
|