[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behaviour on 'read' from a pipe

From: Lluís Batlle i Rossell
Subject: Re: Strange behaviour on 'read' from a pipe
Date: Mon, 2 Apr 2012 16:39:19 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Apr 01, 2012 at 06:27:46PM -0400, Chet Ramey wrote:
> On 4/1/12 1:02 PM, Lluís Batlle i Rossell wrote:
> > On Sun, Apr 01, 2012 at 11:06:22AM -0400, Chet Ramey wrote:
> >> On 4/1/12 5:53 AM, Andreas Schwab wrote:
> >>
> >>>> It looks like a simple race condition.  I suspect that the scheduler
> >>>> arranges things so that the child process ends up exiting between the
> >>>> open and the read, but I don't have any real evidence to back it up.
> >>>
> >>> Note that the opening of the pipe as part of the redirection in the
> >>> parent blocks until there is a writer, ie. until the child opens the
> >>> pipe.  Can this open call return EINTR?
> >>
> >> open() is supposed to return EINTR only if interrupted by a signal.  The
> >> only signal I can see occurring is SIGCHLD, and bash installs the SIGCHLD
> >> handler with SA_RESTART.
> > 
> > Then, any idea of what can be happening?
> It looks like a race condition, like I said.  I can't reproduce it on my
> system, so I don't have anything to troubleshoot.

Trying to reproduce the race, I got rid of 'sleep', and expected this to never
hang. But it hangs where I try. Should I submit this to LKML maybe?

I think it should not hang ever, but maybe I forecast something bad.


rm -f $PIPE
mkfifo $PIPE

function spawn {
    echo DONE > $PIPE

spawn sleep 1 &

while true; do
    echo reading
    while read LINE < $PIPE; do
        echo $LINE
        spawn &

reply via email to

[Prev in Thread] Current Thread [Next in Thread]