Re: Strange behaviour on 'read' from a pipe
On Sat, Mar 31, 2012 at 09:16:20PM -0400, Chet Ramey wrote: > On 3/31/12 9:19 AM, Lluís Batlle i Rossell wrote: > > Hello, > > > > I have this script, that I've found to never write "DONE" in my systems, > > with > > bash 4.0, 4.1, 4.2.. until 4.2-p20, my last test. > > > > However, in irc some people told me it prints DONE for them. If I run the > > script with > > bash under 'strace -f', it also prints DONE. > > 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. > (Like you, my Mac OS X system prints `DONE'.) > > You might want to try using exec to open the FIFO in the parent process > rather than trying to open it on each read. Yes, I know I can work around it, but I meant that the race of the parent getting SIGCHLD in the read call did not bring any useful outcome. For me, useful outcomes could be: - read nothing, and unblock with error - keep on reading the same fd But it does not do any of those. Thank you, Lluís.
Re: Strange behaviour on 'read' from a pipe
Chet Ramey writes: > On 3/31/12 9:19 AM, Lluís Batlle i Rossell wrote: >> Hello, >> >> I have this script, that I've found to never write "DONE" in my systems, with >> bash 4.0, 4.1, 4.2.. until 4.2-p20, my last test. >> >> However, in irc some people told me it prints DONE for them. If I run the >> script with >> bash under 'strace -f', it also prints DONE. > > 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? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Strange behaviour on 'read' from a pipe
On Sun, Apr 01, 2012 at 11:53:12AM +0200, Andreas Schwab wrote: > Chet Ramey writes: > > > On 3/31/12 9:19 AM, Lluís Batlle i Rossell wrote: > >> Hello, > >> > >> I have this script, that I've found to never write "DONE" in my systems, > >> with > >> bash 4.0, 4.1, 4.2.. until 4.2-p20, my last test. > >> > >> However, in irc some people told me it prints DONE for them. If I run the > >> script with > >> bash under 'strace -f', it also prints DONE. > > > > 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? Ah, maybe this is the source trouble. EINTR in open, instead of read. But in this case, even a C program could not be protected against this race other than blocking signals before opening the descriptor. Maybe someone else knows better.
Re: Strange behaviour on 'read' from a pipe
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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange behaviour on 'read' from a pipe
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?
Re: Strange behaviour on 'read' from a pipe
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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
