delorie.com/archives/browse.cgi | search |
Mailing-List: | contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm |
List-Subscribe: | <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com> |
List-Archive: | <http://sources.redhat.com/ml/cygwin-developers/> |
List-Post: | <mailto:cygwin-developers AT sources DOT redhat DOT com> |
List-Help: | <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs> |
Sender: | cygwin-developers-owner AT sources DOT redhat DOT com |
Delivered-To: | mailing list cygwin-developers AT sources DOT redhat DOT com |
Date: | Sat, 15 Sep 2001 23:44:33 -0400 |
From: | Christopher Faylor <cgf AT redhat DOT com> |
To: | cygwin-developers AT cygwin DOT com |
Subject: | possible explanation for make hang |
Message-ID: | <20010915234433.A30407@redhat.com> |
Reply-To: | cygwin-developers AT cygwin DOT com |
Mail-Followup-To: | cygwin-developers AT cygwin DOT com |
Mime-Version: | 1.0 |
User-Agent: | Mutt/1.3.21i |
I don't know precisely what make is doing but it is possible that if more than one program is attempting to read from the same pipe there will be a race that will cause cygwin to block in an uninterruptible read. So, if something like a SIGCHLD comes in while cygwin is reading a pipe it won't be possible to deal with it. I'm not aware of any way to interrupt a blocking read on a pipe so cygwin will hang until something shows up on the pipe. I just had this happen to me after 57 iterations of make in the winsup directory. The stack traces of the affected makes seemed to indicate that this is what is happening. I *really* wish I knew of another way to deal with interrupting reads than the kludge that is now in use but I don't. I thought I had a promising lead a few weeks ago but the Windows API stood staunchly in my path, as usual. Actually, I did have another method for interrupting blocking reads in cygwin at one point. I used to start a new thread for every read on a slow device (such as a pipe) and then call TerminateThread when a signal came in. This approach was met with great horror by other developers when I first started at Cygnus so I reverted it to the current infinitesimally less kludgey approach of (for pipes) polling using PeekNamedPipe for input. The PeekNamedPipe has some drawbacks. It can actually block in some situations and it doesn't detect EOF on Windows 95. Basically, I hate Windows pipes. cgf
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |