X-Spam-Check-By: sourceware.org
From: ericblake AT comcast DOT net (Eric Blake)
To: Linda Walsh <cygwin AT tlinx DOT org>, cygwin AT cygwin DOT com
Subject: Re: cygwin non-posix problems
Date: Sat, 10 Jun 2006 02:11:25 +0000
Message-Id: <061020060211.19532.448A2A4D000864FF00004C4C22007358340A050E040D0C079D0A@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Apr 11 2006)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> >> /bin/kill -f worked for me.
> >>     
>     Hmm....SIGEFF?  Haven't heard of that one.  At least you can
> reproduce it. >>Thank you.<< 

Here,  -f means force, using Windows native methods to kill the process
when cygwin signal handling seems to be stuck.

> > I know! It must be because fork doesn't work on a multi-threaded dual
> > core processor!
> >   
> ---
>     It doesn't?  That sounds nasty, but unfortunately, I'm still
> running on a pokey Mobile Pentium-III, no dualing cores or
> multi-shredded for me! :-)

cgf has been known to add some sarcastic humor to this list - lately
there have been a lot of (unfounded) guesses by newbies that
their dual core is causing cygwin fork problems; but the real root
of the problem is that they had a bad driver pre-installed by Dell
that was corrupting kernel memory.  In short, dual cores are
not the real problem, (neither is repeatedly reinstalling cygwin,
or any other number of trite suggestions that cgf offers
tongue-in-cheek based on the newbie fad of the week).  But
it takes a regular reader of the list to pick up on some of this
humor :)  The use of ! is supposed to be a clue!

> 
>     Since I hadn't had any luck in paring down the test case,
> I thought it might be possible, depending on the debugging tools
> available, to recreate the "hang", then find out why the processes
> don't respond to normal signals, since that shouldn't normally
> happen for POSIX compliant programs, right?

Also bear in mind that cgf has been trying to improve cygwin
signal emulation; trying the latest snapshot will help in this
regards: either it will solve your problem, or you can give
useful feedback to the list that there is still an issue.

The biggest problem that cgf faces is that without simple
test cases, it is nearly impossible to determine where the
bug lies, and he doesn't have time to filter large programs
down to simple cases.

-- 
Eric Blake

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/