Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <3B3B525B.583FFF2B@trex.rtpnc.epa.gov>
Date: Thu, 28 Jun 2001 11:50:51 -0400
From: Greg Smith <rys@epaibm.rtpnc.epa.gov>
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Deadly embrace between pthread_cond_wait and pthread_cond_signal
References: <20010627023524.S19058@redhat.com> <00aa01c0ff1b$44106960$a300a8c0@nhv> <20010627112321.A21615@redhat.com> <037401c0ff5c$ed60ebc0$806410ac@local> <3B3A86CF.DC0FA39A@nc.rr.com> <3B3A87BB.3F7AF46@nc.rr.com> <20010627212201.A27163@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, you are absolutely correct.  Turns out pthread_kill() in the
Pthreads-win32 implementation is essentially a nop and we had changed
our select() in the thread that we want to signal to time-out when
we compile under windows.

So, I'm happy to say, this problem turned out to be a `personal problem' ;-)

Greg

Christopher Faylor wrote:

> >Seems we do a lotta SIGHUPs to break a listening thread out of his
> >reverie, but sometimes the wrong thead (which has done a recv() on a
> >socket) gets woken up instead, and is not particularly happy with the
> >EINTR error code.
> 
> Unless Robert has performed some magic that I'm not aware of, there is
> currently no way to interrupt anything but the main thread in cygwin.
> 
> This has been on my tuit list for a long time but it will require a
> lot of rework of the signal code.
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/